Quectel M35 call rejection problems

IoT Modules GSM Module
1

Hello, I have a problem,
working with my Quectel M35 modem via AT commands (Revision: M35AR01A35, S/N 867144020******)

When i’m calling to my modem, it shows me a RING, so then CLIP with info of caller, but i need to ignore all incoming calls, so i wrote a script that makes ATH on any incoming call

The problem is that ATH works only after second RING announcement, its ignored anyway earlier by modem, how can i fix that?

I.e.:

RING

+CLIP: "+***********",145,"",,"",0

ATH // i'm sending it here
OK // it answeres ok, but call not rejected, waiting...

RING

+CLIP: "+***********",145,"",,"",0 // again

ATH // sending again
OK // its rejected now!

Tried to do that manually with minicom, and may send up to 5 times ATH with OK answer that ignored until second RING echoed…

So, are any firmwares for this modem maybe that fixed that thing or any firmware with AT+GSMBUSY support here?

Thank you!

2

I have the same problem with M66 module. It is strange, but I observe it only when calling from iPhone.

3

Hi all, I have a similar problem but with M26/M66 modules.

Depending on the MNO I need to refuse the call one or multiple times… Another thing that does not work like in any other mobile phone is the diversion.

When I configure “busy diversion” on my phone and then reject a call while ringing, the call is forwarded to the “busy diversion” number. If I use “ATH” while ringing, the call is rejected but without diversion.

This behaviour suggested me that the call is not rejected with a 17 (user busy) disconnect cause (as usual), but with something different. I’ve tried to call (using a M26) my mobile and another module. Using AT+CEER after the end of the call I confirmed that the quectel module reject with 21 (Call rejected) cause, and not with 17!

I guess that some MNO doesn’t like/understand the 21 disconnect cause and than re-try the call. This may explain why niceque get the incoming call more than once!

@quectel: is it possible to have a “fixed” firmware version that send 17 (user busy) as disconnect cause, when sending ATH during “RINGING” ?!? (otherwise AT+GSMBUSY may be a good alternative)

Thank you and best regards

Paolo

4

Hi Paolo:
Could you tell me the software version of the modules(excute ATI to check) and the specific AT steps that you performed?
You can send us a screenshot of the failed AT steps or save the ATLOG to us,thanks.

5

Hello, I’ve made two tests using a GoIP (from DBLTech) box, that uses M26 modules.
I don’t have the details of my original tests, but they confirmed the same behavior on a M66 module on a GSMEVB-KIT board (if you need I’ll try again, but I need a while).

Test#1: call from M26 (M26FBR03A02_RSIM) to M26 (M26FBR03A02_RSIM)

Calling Module:

08:54:20.785 gsm_atd(): atcmd.c: 399: channel1 dialing cmd: ATD+39351187xxxx;
08:54:20.842 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK
08:54:21.492 gsm_write(): atcmd.c: 291: channel1 ATD+39351187xxxx;
08:54:21.622 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK
08:54:21.682 parse_tty_info(): console.c: 2050: ttyS1:len=39 +CLCC: 1,0,2,0,0,"+39351187xxxx",145,""
08:54:28.012 gsm_write(): atcmd.c: 291: channel1 AT+CSQ
08:54:28.162 parse_tty_info(): console.c: 2050: ttyS1:len=10 +CSQ: 16,0
08:54:28.222 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK
08:54:32.872 parse_tty_info(): console.c: 2050: ttyS1:len=39 +CLCC: 1,0,3,0,0,"+39351187xxxx",145,""
08:54:34.882 parse_tty_info(): console.c: 2050: ttyS1:len=39 +CLCC: 1,0,6,0,0,"+39351187xxxx",145,""
08:54:34.883 gsm_write(): atcmd.c: 291: channel1 ATH
08:54:35.032 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK
08:54:35.122 parse_tty_info(): console.c: 2050: ttyS1:len=4 BUSY
08:54:35.892 gsm_write(): atcmd.c: 291: channel1 AT+CEER
08:54:36.082 parse_tty_info(): console.c: 2050: ttyS1:len=11 +CEER: 1,21
08:54:36.142 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK

(21 = Call rejected)

08:43:59.492 gsm_write(): atcmd.c: 291: channel1 ATI
08:43:59.632 parse_tty_info(): console.c: 2050: ttyS1:len=11 Quectel_Ltd
08:43:59.662 parse_tty_info(): console.c: 2050: ttyS1:len=11 Quectel_M26
08:43:59.692 parse_tty_info(): console.c: 2050: ttyS1:len=26 Revision: M26FBR03A02_RSIM
08:43:59.752 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK

Note:
On the number +39351187xxxx the “busy” diversion is configured (to +390xxxxxxxxx), but the call is not forwarded.

Receiving module:

08:54:32.308 parse_tty_info(): console.c: 2050: ttyS2:len=39 +CLCC: 1,1,4,0,0,"+447xxxxxxxxx",145,""
08:54:32.348 parse_tty_info(): console.c: 2050: ttyS2:len=4 RING
08:54:32.408 parse_tty_info(): console.c: 2050: ttyS2:len=35 +CLIP: "+447xxxxxxxxx",145,"",,"",0
08:54:34.344 gsm_write(): atcmd.c: 291: channel2 ATH
08:54:34.478 parse_tty_info(): console.c: 2050: ttyS2:len=39 +CLCC: 1,1,6,0,0,"+447xxxxxxxxx",145,""
08:54:34.658 parse_tty_info(): console.c: 2050: ttyS2:len=2 OK

08:58:43.149 gsm_write(): atcmd.c: 291: channel2 ATI
08:58:43.268 parse_tty_info(): console.c: 2050: ttyS2:len=11 Quectel_Ltd
08:58:43.298 parse_tty_info(): console.c: 2050: ttyS2:len=11 Quectel_M26
08:58:43.328 parse_tty_info(): console.c: 2050: ttyS2:len=26 Revision: M26FBR03A02_RSIM
08:58:43.388 parse_tty_info(): console.c: 2050: ttyS2:len=2 OK

Test #2: call from M26 (M26FBR03A02_RSIM) to Nokia E51 (pressing “decline” button when ringing)

08:42:00.822 gsm_write(): atcmd.c: 291: channel1 ATD+39351187xxxx;
08:42:00.952 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK
08:42:01.012 parse_tty_info(): console.c: 2050: ttyS1:len=39 +CLCC: 1,0,2,0,0,"+39351187xxxx",145,""
08:42:07.332 gsm_write(): atcmd.c: 291: channel1 AT+CREG?
08:42:07.462 parse_tty_info(): console.c: 2050: ttyS1:len=24 +CREG: 2,5,"4E73","D283"
08:42:07.522 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK
08:42:09.112 parse_tty_info(): console.c: 2050: ttyS1:len=39 +CLCC: 1,0,3,0,0,"+39351187xxxx",145,""
08:42:12.562 parse_tty_info(): console.c: 2050: ttyS1:len=39 +CLCC: 1,0,6,0,0,"+39351187xxxx",145,""
08:42:12.562 gsm_write(): atcmd.c: 291: channel1 ATH
08:42:12.742 parse_tty_info(): console.c: 2050: ttyS1:len=4 BUSY
08:42:12.802 parse_tty_info(): console.c: 2050: ttyS1:len=2 OK
08:42:13.562 gsm_write(): atcmd.c: 291: channel1 AT+CEER
08:42:13.672 parse_tty_info(): console.c: 2050: ttyS1:len=11 +CEER: 1,17

(17 = User busy)

Note:
On the number +39351187xxxx the “busy” diversion is configured (to +390xxxxxxxxx), the call IS FARWARDED to the “busy diversion” number that gives “Busy”

Evidence of forwarded call received on Asterisk:

 -- Executing [+390xxxxxxxxx@unauth-sip:1] NoOp("SIP/ispname.it-00007472", ""+447xxxxxxxxx" <+447xxxxxxxxx> - 08-03-2021 08:42:11") in new stack
 -- Executing [+390xxxxxxxxx@unauth-sip:2] Set("SIP/ispname.it-00007472", "Contact=<sip:+447xxxxxxxxx.iIiIiI.0a0d0eae.@6x.xx.xx.xxx:5060>") in new stack
 -- Executing [+390xxxxxxxxx@unauth-sip:3] Set("SIP/ispname.it-00007472", "HistoryInfo=<tel:351187xxxx?Privacy=none>;index=1,  <tel:0xxxxxxxxx;cause=486>;index=1.1") in new stack
 -- Executing [+390xxxxxxxxx@unauth-sip:4] AGI("SIP/ispname.it-00007472", "testNumber.php") in new stack
 -- Launched AGI Script /var/lib/asterisk/agi-bin/testNumber.php
 -- AGI Script Executing Application: (Busy) Options: ()

Let me know if you need more evidences.
Best Regards
Paolo

6

Hi Paolo:
About AT+CEER issues,you need to use the Catcher tool to grab the log for R&D to analysis.If need to more assistance,pls reach to support@quectel.com.

7

Hi Winnie, where can I find the “Catcher tool” ?
I’ll need to use it with the GSMEVB board, or it is also available for GoIP products?

Honestly I don’t understand why you’re calling this “AT+CEER issues”… I’m convinced that the problem affect the ATH command, the AT+CEER just shows the different disconnect causes.

Anyway, I’ll write also to support@quectel.com
I hope I can help you solving this strange issue.

Paolo

8

Hi Paolo:
Catcher is the log tool for Windows system.I will send it by email.
For details, please grab the log and send it to support@quectel.com
Wish you all the best.

9

I resolved problem. For rejection call use AT+CHLD=0 (not ATH0). For disconnecting existing connection use ATH0.

10

Hi anyone !

First of all: thank you Jacek, I confirm that using AT+CHLD=0, the call is rejected with Busy, and then the “busy diversion” (i.e. voicemail) works properly!

I’ve made the two tries using the catcher software and (I hope I’ve understood correctly) it seems that ATH use “16” as disconnection cause, and AT+CHLD=0 use “17”. Probably the “21” that I see on the calling party, is a re-mapped message, from an operator that don’t expect to receive “16” as disconnecting cause of a not-answered call! (this occasionally make the operator to retry call, as observed by niceque).

1444×851 78.6 KB

1444×851 75.3 KB

My “problem” is that I’m using GoIP boxes (from DBLTech), so I cannot modify the AT command that is used for reject a ringing call (that is ATH).

Is it possible to have a patched version of the firmware, with 17 cause for the ATH command?

I’m currently using M66FAR02A07BT as firmware for the M66 module on the GSMEVB-KIT board and M26FBR03A02_RSIM on my GoIP boxes.

Let me know if I can do anything else to help.
Best Regards
Paolo

P.S.

I’m sending the full dump file from Catcher to support.

11

Hi Paolo:
Does you mean you can only use ATH to hang up the call and want it with 17 cause?
It is transferred by MTK according to the network signaling in the CALL, so this is usually not modified.

12

Hi Winnie:
Yes, GoIP are third party VoIP-to-GSM gateways, which uses Quectel M26 modules (currently with M26FBR03A02_RSIM firmware), so there is no way (for me) to modify the AT command used when the call is declined while ringing.

In my opinion the use of 16 cause, while the call is ringing and not answered, is just wrong/non-standard. Any mobile phone (and all GSM module I have ever used) send the 17 cause when declining an incoming call.

May be that the MTK just send 16 on ATH, without care about the state of the call (answered or not). Sadly, this behavior is buggy and produce some side effects: it make the calling network re-try the call multiple times (as noticed by niceque), it breaks the voice mail and any other forwarding on busy.

The simplest test is the voice mail: usually when you decline a call, the caller listen the voice mail welcome message. With a M26 module, sending ATH while ringing does not trigger the voice mail.

Let me know if I can do anything else
Best Regards
Paolo

13

Hi Paolo:
I have feed back your requirements to our R&D.If you do need this feature, you can contact your local FAE or contact support@quectel.com directly.