Outgoing Calling Sequence HL85

Hi I am using Q2687 GSM MODEM MODULE with AT&T operator. I implemented outgoing calling control using XCALLSTAT. But sometimes modem is responding with +XCALLSTAT: 1,3 indicating rining but even though the call is not established. This causes us to miss making some calls. Can anybody let me know how to handle the outgoing calling sequence?

Transaction When Call is Answered:
->ATH
<-OK
->ATD+;
<-OK
<-+XCALLSTAT: 1,2
<-+XCALLSTAT: 1,3
<-+XCALLSTAT: 1,7
<-+XCALLSTAT: 1,0
<-+COLP: “”,145
->AT+CLVL=10
<-OK
->ATH
<-OK
<-+XCALLSTAT: 1,6

Transaction When Call is Not Answered (international number withou voice mail):
->ATH
<-OK
->ATD+;
<-OK
<-+XCALLSTAT: 1,2
<-+XCALLSTAT: 1,3
->ATH
<-OK
<-+XCALLSTAT: 1,6

Hi,

Can you clarify the title and the first statement that you have made i.e. the title says HL8 (which lines up with the XCALLSTAT command) but the first statement you have made is that you are using the Q2687?

Re the actual problem its not entirely clear what the issue is, you get the ringing indication through (1,3) and the other end does or does not pick up? The XCALLSTAT indications are literally a translation of the layer 3 messages coming from the network to the unit, it is not interpreting/changing them. The important indication is the 1,7 one as the network needs this since it is from this point that you start to be charged.

All I can suggest is that you have a time out (value dependent on what your system does) running from the 1,2 indication (because the alerting is sometimes not given depending on the network and where the call is going to) and if the call is not connected after the time out you hang it up as per the above. The unit is giving the disconnected 1,6 response confirmation so this is working properly and you will know whaere you are with the call state.

Regards

Matt

Hi Matt,

Our system is supposed to make three calls and three text messages on an event, sometimes we noticed it missing one of the calls. When debugged it seems like our internal call monitoring timer expires before the call was established. We have updated software to retry if the call didn’t go to XCALLSTAT: 1,3 stage but still we are missing some calls occasionally. I am looking for something to let me know when the connection is complete so that I can stop retry. I can’t rely on XCALLSTAT: 1,7 because we are not supposed to retry if the user rejects the call.

What is the best way to handle the outgoing calls to make sure all calls properly completed?

Thanks for the response.

I would have expected you to see the 1,6 (disconnected) come back if they rejected the call especially as you see it when you terminate the call with ath. You could try the at+cpas command when your timer expires, if its state is 0 then you know the unit is not in the process of making the call and assuming you have not got the 1,6 back then you can see what state the unit is in.

Regards

Matt