What to do if ttyUSB number change?

For example, you plug two modems but in different order, and when plug modem X first it becomes /dev/ttyUSB[0-2] (dongle0 as defined in dongle.conf)
But if plug modem Y first it becomes /dev/ttyUSB[0-2] (dongle0) and modem X becomes /dev/ttyUSB[3-5] (dongle1)
The same can happen when rebooting computer, sometimes X becomes dongle0, but sometimes dongle1.
To avoid this indetermination you may use

udev rules

Create /etc/udev/rules.d/99-huawei-link.rules with the following lines

# add symlinks for device based on USB bus address i.e. physical USB slot 
ACTION!="add|change", GOTO="device_huawei_end" 
#SUBSYSTEM!="usb", GOTO="device_huawei_end" 
#ATTRS{idVendor}!="12d1", GOTO="device_huawei_end" 
#ATTRS{idProduct}=="1446", GOTO="device_huawei_link" 
#ATTRS{idProduct}=="140c", GOTO="device_huawei_link" 
#ATTRS{idProduct}=="1001", GOTO="device_huawei_link" 
#GOTO="device_huawei_end" 

LABEL="device_huawei_link" 

# USB slot from left to right (back look) 
# left 
KERNEL=="ttyUSB[0-9]*", ID=="1-1:1.0", SYMLINK+="hw-modem-0" 
KERNEL=="ttyUSB[0-9]*", ID=="1-1:1.1", SYMLINK+="hw-audio-0" 
KERNEL=="ttyUSB[0-9]*", ID=="1-1:1.2", SYMLINK+="hw-data-0" 
KERNEL=="ttyUSB[0-9]*", ID=="1-1:1.3", SYMLINK+="hw-net-0" 

# left middle
KERNEL=="ttyUSB[0-9]*", ID=="1-2:1.0", SYMLINK+="hw-modem-1" 
KERNEL=="ttyUSB[0-9]*", ID=="1-2:1.1", SYMLINK+="hw-audio-1" 
KERNEL=="ttyUSB[0-9]*", ID=="1-2:1.2", SYMLINK+="hw-data-1" 
KERNEL=="ttyUSB[0-9]*", ID=="1-2:1.3", SYMLINK+="hw-net-1" 

# right middle
KERNEL=="ttyUSB[0-9]*", ID=="1-3:1.0", SYMLINK+="hw-modem-2" 
KERNEL=="ttyUSB[0-9]*", ID=="1-3:1.1", SYMLINK+="hw-audio-2" 
KERNEL=="ttyUSB[0-9]*", ID=="1-3:1.2", SYMLINK+="hw-data-2" 
KERNEL=="ttyUSB[0-9]*", ID=="1-3:1.3", SYMLINK+="hw-net-2" 

# right 
KERNEL=="ttyUSB[0-9]*", ID=="1-4:1.0", SYMLINK+="hw-modem-3" 
KERNEL=="ttyUSB[0-9]*", ID=="1-4:1.1", SYMLINK+="hw-audio-3" 
KERNEL=="ttyUSB[0-9]*", ID=="1-4:1.2", SYMLINK+="hw-data-3" 
KERNEL=="ttyUSB[0-9]*", ID=="1-4:1.3", SYMLINK+="hw-net-3" 

LABEL="device_huawei_end" 

In this case, ID == “” indicate what is displayed in your dmesg output after plug the modem in this USB port in lines of like

[ 4854.344460] option 1-1:1.0: GSM modem (1-port) converter detected 

In dongle.conf use this symbolic links instead of /dev/ttyUSBx files

[dongle0] 
audio=/dev/hw-audio-0 
data=/dev/hw-data-0 

modems discovery

Since Jan 08, 2011 and revision 150 of http://code.google.com/p/asterisk-chan-dongle you can use also simple but powerful feature - discovery modems by IMEI or/and IMSI numbers. For example:

[dongle0]
imei=123456789012345

[dongle1]
imsi=543210987654321

[dongle2]
imei=999999999999999
imsi=888888888888888

Each time before device opening chan_dongle will search for devices with predefined VendorID:ProductID pairs, detect ports or this devices, and check its IMEI and IMSI.

modem detaching from system when trying to call

When received incoming call or begining outgoing call chan_dongle lost connection to device and device disappears from system, but after a while, it comes back.
In asterisk CLI appears something like that

-- Attempting call on Dongle/dongle0/7495**** for application Playback(silence/10) (Retry 1) 
-- Dongle dongle0 has disconnected 
[Dec 30 16:12:09] NOTICE[26493]: pbx_spool.c:339 attempt_thread: Call failed to go through, reason (1) Hangup 
debian*CLI> 
-- Dongle dongle0 trying to connect on /dev/ttyUSB2... 
-- Dongle dongle0 has connected, initializing... 
-- Dongle dongle0 initialized and ready

In kernel log and dmesg

Dec 30 15:14:10 VoipGSM kernel: [ 864.438822] option: option_instat_callback: error -84 
Dec 30 15:14:10 VoipGSM kernel: [ 864.448060] usb 5-1: USB disconnect, address 3 
Dec 30 15:14:10 VoipGSM kernel: [ 864.448817] option: option_instat_callback: error -108

A possible reason is bad firmware 11.608.12.10.209 in Huawei E1550. This version of firmware allow voice calls in Windows with Mobile Partner, but seems not to work in Linux :)
Another reason is the lack of power for device at peak load when call is starting.

SMS and USSD truncated to first \n symbol

For example you send “Hello!\nHow are you?” but asterisk show only “Hello!”
The reason for this hidden in asterisk variable subsitution, and can be solved by use BASE64_DECODE function:

${BASE64_DECODE(${SMS_BASE64})}
${BASE64_DECODE(${USSD_BASE64})}

Caller party not hearing ringback tone

When forward call from GSM → SIP caller party does not hear ringback tone.
To solve this problem you can use add options 'm' (music on hold) or 'r' for Dial() application

exten => s,n,Dial(SIP/111@sip,30,m)
exten => s,n,Dial(SIP/111@sip,30,r)

DTMF symbols A,B,C,D not sent by chan_dongle

Sorry, but Huawei modems not support sending this symbols, and asterisk try to send these symbols in band.

DTMF symbols not received from dongle

At first, DTMF in GSM network are sent over a voice channel, this mean you must first answer to incoming call or establish outgoing for receive DTMF.
Other possible reason is usage of asterisk version 1.6.2.16-rc1, return back to 1.6.2.13 solve this trouble.
Check setting of dongle.conf

dtmf=inband

or

dtmf=relax

In case of problems with DTMF we recommend enable dtmf logging in logger.conf

dtmf => dtmf

DTMF symbols not sent to dongle

At first, DTMF in GSM network are sent over a voice channel, this mean you must first answer to incoming call or establish outgoing for send DTMF.

Duplicate of received DTMF symbols

Has several reasons of duplication of DTMF:

• when asterisk receive DTMF symbol from chan_dongle it passed symbol to other leg of call but DTMF tones also passed in band. I.e. other side receive duplicated DTMF symbol
• GSM network vulnerable for echo
• GSM phone of party also produce echo

For these reasons DTMF symbol can walk infinitely from phone to phone if asterisk bridge GSM and GSM.