bg111 / asterisk-chan-dongle

Automatically exported from code.google.com/p/asterisk-chan-dongle
Other
351 stars 315 forks source link

E171 with 21.157.00.01.143 firmware permanently restarts when call goes to IVR #240

Open VGBLTSK opened 7 years ago

VGBLTSK commented 7 years ago

Chan_dongle Gurus, Has anyone faced the problem using HISILICON chipset based modems with 21.156.00.01.143 or 21.157.00.01.143 firmware onboard when invoking Asterisk IVR menu results into dongle (modem) reboot? I performed some testing and it seems that Answer() or Playback() commands are causing modem to be immediately restarted, whereas I can make\receive any direct call. This problem is not observed for Huawei e1550 (firmware 11.XX). The strange thing is I can seamlessly make\receive direct inbound\outbound calls (dongle – sip\softphone). I can also 'talk' to the dongle via socat tool and issue AT command to answer the call as below:

RING
ATA
^RSSI: 28
OK
^CONN:1,0
^RSSI: 26
^RSSI: 25
^RSSI: 24

However Asterisk regular command Answer() or Playback() results into resetting the dongle:

chunk of Incoming context that makes dongle restart:

[incoming]
exten => s,n(incoming_tree),NoOp(provider = ${DONGLEPROVIDER})
exten => s,n,Answer(500)
exten => s,n,Background(/var/lib/asterisk/sounds/sometext)
exten => s,n,WaitExten(5)
exten => s,n,Goto(incoming_tree)
exten => s,n,HangUp()
-- [2017-01-03 13:36:38] ERROR[27359]: chandongle.c:436 domonitorphone: [MTS] timedout while waiting 'OK' in response to 'AT'
[MTS] Dongle has disconnected
This is what observed in a CLI when the call goes to IVR:
-- Executing [s@incoming:18] NoOp("Dongle/MEGA-0100000001", "") in new stack
-- Executing [s@incoming:19] Answer("Dongle/MEGA-0100000001", "500") in new stack
-- Executing [s@incoming:20] BackGround("Dongle/MEGA-0100000001", "/var/lib/asterisk/sounds/sv") in new stack
-- <Dongle/MEGA-0100000001> Playing '/var/lib/asterisk/sounds/sv.gsm' (language 'en')
-- Executing [s@incoming:21] WaitExten("Dongle/MEGA-0100000001", "5") in new stack
[2017-01-02 14:44:05] ERROR[27070]: chan_dongle.c:436 do_monitor_phone: [MEGA] timedout while waiting 'OK' in response to 'ATA'
== Spawn extension (incoming, s, 21) exited non-zero on 'Dongle/MEGA-0100000001'
-- [MEGA] Dongle has disconnected
-- [MEGA] IMSI XXXXXXXXXXXXXXX found on data_tty=/dev/ttyUSB4 audio_tty=/dev/ttyUSB5
-- [MEGA] Trying to connect on /dev/ttyUSB4...
-- [MEGA] Dongle has connected, initializing...
-- [MEGA] Dongle initialized and ready

And this is worth of noting: 'timedout while waiting 'OK' in response to 'ATA' - makes me to believe, that some commands are not recognized by chan_dongle. I poked around a bit and ascertained that the the set of AT commands is slightly different

For example, Qualcomm chipset based dongles make use of AT^U2DIAG=0 for setting up device as modem only, whereas HiSilicon based device accepts at^setport=»a1,a2;1,2,3″.

AT^U2DIAG=0 modem only
AT^U2DIAG=1 modem only + CD-ROM
AT^U2DIAG=255 modem only + CD-ROM + Card Reader
AT^U2DIAG=256 modem only + Card Reader
AT^U2DIAG=292 - modem only + card reader + G interface

AT-commands for Huawei dongles E171 with firmware v21.156.00.00.143:

AT^SETPORT="A1,A2,1,2,3,7,A1,A2" (Default configuration)
AT^SETPORT="A1,A2,1,2,3,7" (modem + network card)
AT^SETPORT="A1,A2;1,2,3,A2" (modem + card reader)
AT^SETPORT="A1,A2;1,2,3" (modem only)

Any ideas why my dongles keep on restarting when call goes to IVR are highly appreciated.

Thank you. With regards, Evgenii.

VGBLTSK commented 7 years ago

Nobody?

marcoaa commented 7 years ago

Dear Evgenii,

There a big problem with Hisilicon chipsets and DTMF. The IVR uses DTMF, than doesn't work. I still don´t understood because is necessary to disable 3G MODE to make calls. Good Lucky.

Regards.

Marco Araujo.

VGBLTSK commented 7 years ago

Hello Marco Araujo. Thank you for your comments. I am a bit unclear - you said I have to disable 3G mode to make calls. In fact - I used to disable it all along. And as I wrote before - I can make\receive calls. However, dongle reboots when call route goes through IVR. I would dare to say that DTMF is used when caller is expected to make a choice. Whereas, my issue that a dongle goes into reboot before user can send DTMF signal - it breaks once Answer command is issued by Asterisk. I do suspect that there is trouble with AT commands used for dongle. It makes me wonder if the problem can be worked around before I trash those dongles.

All the best, Evgenii.

marcoaa commented 7 years ago

Hello Evgenii, I have try with this parameters below in dongle.conf and the IVR worked properly. But I never try to make IVR with Hisilicom chipsets, my good experience was with E1756, chipset MSM6190 I guess. Good Lucky my friend.

dtmf=relax mindtmfgap=45 mindtmfduration=10 mindtmfinterval=20

bg111 commented 7 years ago

better if set gap = min (0), duration to min (0), and interval to min (0) possible values

dtmf can be "off", "inband", "relax"

dtmf can be read/write by CHANNEL function

marcoaa commented 7 years ago

Hello bg111, how are you? I remember I configured dtmf=off and the IVR didn't work properly. In my case I use E1756 Dongle, chipset MSM6290. Thank you.

Regards.

VGBLTSK commented 7 years ago

Gentlemen, The only way to work the issue around (which is a good question itself whether it is a workaround indeed) is to send a call to another channel which can ‘Answer’ the call and process through its own IVR. I have a separate trunk for GV and it seems to be working. So, it goes like this: Dongle -> GV1 trunk (Answer + user makes a choice + DTMF) -> Dial SIP trunk. Really cumbersome and awkward, but working….