Dropped Incoming calls after 20 seconds, Reason: Q.850;cause=86

[Carlos Guardia Prudencio]

I have the following scenario for incoming calls:

PSTN ---- E1 ---> Digium Gateway --- SIP ---> Router 2921 ------SIP ----> CUCM

All incoming calls from the PSTN get dropped after 20 seconds. All outgoing calls to the PSTN work fine..

The Router 2921 generates a BYE message with Reason: Q.850;cause=86 to the Digium Gateway.

Attached is the debug, show run and a packet capture with all the SIP messages..

If someone could please give me to a solution.

Thanks!

[Karthik Sivaram · Accepted solution]

Hello  Carlos,

Here is the analysis of the traces....

Timestamp                 Node / Interface   Device IP      Direction   Protocol   Message Name                              TCP Handle / From Tag                                  Call Ref / ID                                    
05/09/2014 16:52:36.608   172.17.0.6         172.16.50.10   In          SIP        INVITE                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:36.620   172.17.0.6         172.17.0.3     Out         SIP        INVITE                                    A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:36.620   172.17.0.6         172.16.50.10   Out         SIP        100 Trying                                as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:36.624   172.17.0.6         172.17.0.3     In          SIP        100 Trying                                A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:36.632   172.17.0.6         172.17.0.3     In          SIP        180 Ringing                               A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:36.632   172.17.0.6         172.16.50.10   Out         SIP        180 Ringing                               as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:39.140   172.17.0.6         172.17.0.3     In          SIP        200 OK                                    A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:39.144   172.17.0.6         172.17.0.3     In          SIP        SUBSCRIBE                                 844851~97a97412-a383-4ad3-9458-162b2737f313-47291175   AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:39.148   172.17.0.6         172.17.0.3     Out         SIP        ACK                                       A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:39.148   172.17.0.6         172.17.0.3     Out         SIP        200 OK                                    844851~97a97412-a383-4ad3-9458-162b2737f313-47291175   AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:39.148   172.17.0.6         172.17.0.3     Out         SIP        NOTIFY                                    A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:39.152   172.17.0.6         172.17.0.3     In          SIP        200 OK                                    A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   
05/09/2014 16:52:39.152   172.17.0.6         172.16.50.10   Out         SIP        200 OK                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:39.652   172.17.0.6         172.16.50.10   Out         SIP        200 OK                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:40.652   172.17.0.6         172.16.50.10   Out         SIP        200 OK                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:42.652   172.17.0.6         172.16.50.10   Out         SIP        200 OK                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:46.652   172.17.0.6         172.16.50.10   Out         SIP        200 OK                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:50.652   172.17.0.6         172.16.50.10   Out         SIP        200 OK                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:54.652   172.17.0.6         172.16.50.10   Out         SIP        200 OK                                    as12f8f5d4                                             516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:58.652   172.17.0.6         172.17.0.6     Out         SIP        BYE                                       A424AFAC-1EC1                                          516d02ad77ed3cf82e1afbdd030cc1d1@172.17.0.6      
05/09/2014 16:52:58.652   172.17.0.6         172.17.0.3     Out         SIP        BYE                                       A424AFA0-1D7B                                          AF81DF7A-D6F211E3-967988BC-FD349507@172.17.0.6   

The  200 Ok is  not being acknowledged  by the  Digium Gateway .  Hence the call is dropped .

Please check why  the "Digium" side is not sending an ACK  for this transaction.

Hope this  helps!

Regards,

Karthik Sivaram

[Carlos Guardia Prudencio]

Thanks a lot Karthik... based on your analysis.. it makes sense that exactly after 19 o 20 seconds the call gets dropped.. did you make this capture based on the debugs..? or based on the wireshark capture attached?

This wireshark capture was taken directly from the digium gateway.. and in the capture you can see an ACK being generated for every OK received.. could it be that the router isnt processing the ACK generated by the digium ?

Thanks

[Karthik Sivaram]

Hello Carlos,

The packet cap from the Digium does show  ACKs being sent .  

Would you be able to collect  2  simultaneous  packet captures    one   from  the Digium and the  other   from the cisco  gateway at the same time ? 

This will  show us  if   the packets are fragmented  or  if the ack is not  processed / received  by the gateway  also it  will give  us information on the timestamps  for the exchanges on both ends .

Here is the procedure to collect  the packet capture from the cisco gateway :-

http://www.cisco.com/c/en/us/support/docs/voice/h323/116078-technologies-technote-commandreference-00.html#anc5

Regards,

Karthik Sivaram

[Carlos Guardia Prudencio]

Karthik,

After playing with the options that the digium gateway lets you modified.. I managed to get it working changing the NAT Traversal setting from NO to YES...

Once I did this change.. the incoming calls are not dropping...

If this is all on the same LAN.. why would this NAT parameter affect the ACKs or OKs .??

Thanks for your help!

[Karthik Sivaram]

Great to know that !!

So the NAT configuration on  Digium possibly corrupted or fragmented the  sip packets for ACK.

We can see this if you can collect the packet captures I mentioned in my earlier post  this will conclusively prove  if there were fragmented / dropped  packets  when the ACK  was sent  to the Cisco side  or  the Cisco gateway didn't even receive it .

Hope this helps!

Regards,

Karthik Sivaram

[jeanmallet2000]

From where did you perform the trace and what commands have you used ?

[SusanaChumpitasi]

We were experiencing the same problem. Calls being dropped after 20 seconds. And also had the same call termination code:

Reason: Q.850;cause=86

Problem was solved by rebooting both of our voice gateways. It seems the CPE had a few seconds power failure. Which seemed to had lost the handshake with CPE.