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.
