7821 SIP phone issue with CME 10.5

[ahmed-hassan1110]

Hi Gents,

I have a setup of CME 10.5 on 2911 ISR in the HQ, then i have a DMVPN to the branch site.

I have the following phone types:

- 7945 skinny based phone.

- 8831 SIP conference station.

-7821 SIP phones.

- 7861 SIP phone.

the setup is working fine in the HQ (on the same LAN) but when i took some of the 7821 phones and placed them in the branch site the following happens:

- They are able to register to the CME in the HQ.

- Branch phones can call all HQ phones normally.

- The issue is that HQ 7821 & 7861 phones can not call 7821 branch phones (no ring back is heared then the call disconnects after around 1 minute), despite the fact that HQ 7945 and 8831 (which is also SIP based) can call Branch 7821 phones normally with no issues ???

I have upgraded the router IOS to the latest safe harbor version 15.4(3)M4 and upgraded the 7821 firmware to the latest version 10.3.1 with no success.

I have enabled the debug voice ccapi inout and collected the output from 2 calls, 1 is from HQ 8831 SIP phone to a branch 7821 phone which was successful and the other from HQ 7821 phone to a branch 7821 phone which was unsuccessful and i compared the two outputs line by line and discovered that in the successful call the alerting singal (ring back) is received normally, but in the unsuccessful one it's not received and a disconnect signal is received as shown below:

- successful call:

*Oct 25 10:43:55.258: cc_api_get_xcode_stream : 4982
*Oct 25 10:43:55.258: //678/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
*Oct 25 10:43:55.258: cc_api_get_xcode_stream : 4982
*Oct 25 10:43:55.258: //678/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
*Oct 25 10:43:55.258: cc_api_get_xcode_stream : 4982
*Oct 25 10:43:55.258: //678/1F64117E85C0/CCAPI/cc_api_call_proceeding:
   Interface=0x3E81FC6C, Progress Indication=NULL(0)
*Oct 25 10:43:55.466: //678/1F64117E85C0/CCAPI/cc_api_call_alert:
   Interface=0x3E81FC6C, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
*Oct 25 10:43:55.466: //678/1F64117E85C0/CCAPI/cc_api_call_alert:
   Call Entry(Retry Count=0, Responsed=TRUE)
*Oct 25 10:43:55.470: //677/1F64117E85C0/CCAPI/ccCallAlert:
   Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
*Oct 25 10:43:55.470: //677/1F64117E85C0/CCAPI/ccCallAlert:
   Call Entry(Responsed=TRUE, Alert Sent=TRUE)
*Oct 25 10:43:55.470: //677/1F64117E85C0/CCAPI/ccCallNotify:
   Data Bitmask=0x7, Call Id=677

- unsuccessful call:

*Oct 25 08:18:21.359: cc_api_get_xcode_stream : 4982
*Oct 25 08:18:21.359: //357/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
*Oct 25 08:18:21.359: cc_api_get_xcode_stream : 4982
*Oct 25 08:18:21.359: //357/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
*Oct 25 08:18:21.359: cc_api_get_xcode_stream : 4982
*Oct 25 08:18:21.359: //357/C9AD33DD82E1/CCAPI/cc_api_call_proceeding:
   Interface=0x3E81FC6C, Progress Indication=NULL(0)

*Oct 25 08:19:24.863: //357/C9AD33DD82E1/CCAPI/cc_api_call_disconnected:
   Cause Value=102, Interface=0x3E81FC6C, Call Id=357
*Oct 25 08:19:24.863: //357/C9AD33DD82E1/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=102, Retry Count=0)
*Oct 25 08:19:24.863: //356/C9AD33DD82E1/CCAPI/ccCallReleaseResources:
   release reserved xcoding resource.
*Oct 25 08:19:24.863: //357/C9AD33DD82E1/CCAPI/ccCallSetAAA_Accounting:
   Accounting=0, Call Id=357
*Oct 25 08:19:24.863: //357/C9AD33DD82E1/CCAPI/ccCallDisconnect:
   Cause Value=102, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=102)
*Oct 25 08:19:24.863: //357/C9AD33DD82E1/CCAPI/ccCallDisconnect:
   Cause Value=102, Call Entry(Responsed=TRUE, Cause Value=102)
*Oct 25 08:19:24.863: //357/C9AD33DD82E1/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x3E81FC6C, Tag=0x0, Call Id=357,
   Call Entry(Disconnect Cause=102, Voice Class Cause Code=0, Retry Count=0)
*Oct 25 08:19:24.863: //357/C9AD33DD82E1/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
*Oct 25 08:19:24.863: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   
*Oct 25 08:19:24.863: :cc_free_feature_vsa freeing 24DE2870
*Oct 25 08:19:24.863: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   
*Oct 25 08:19:24.863:  vsacount in free is 1
*Oct 25 08:19:24.863: //356/C9AD33DD82E1/CCAPI/ccCallDisconnect:
   Cause Value=102, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
*Oct 25 08:19:24.863: //356/C9AD33DD82E1/CCAPI/ccCallDisconnect:
   Cause Value=102, Call Entry(Responsed=TRUE, Cause Value=102)
*Oct 25 08:19:24.871: //356/C9AD33DD82E1/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x3E81FC6C, Tag=0x0, Call Id=356,
   Call Entry(Disconnect Cause=102, Voice Class Cause Code=0, Retry Count=0)
*Oct 25 08:19:24.871: //356/C9AD33DD82E1/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
*Oct 25 08:19:24.871: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   
*Oct 25 08:19:24.871: :cc_free_feature_vsa freeing 24DE25D0
*Oct 25 08:19:24.871: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   

so any ideas?

[Carlo Poggiarelli]

Hi Ahmed.

You are receiving a 102 cause code value which means that remote end is not responding to sip invites from CME.

Can you please attach a debug ccsip message ?

Thanks

Regards

Carlo

[ahmed-hassan1110]

please find debug ccsip message for a call from extension 204 in HQ to 201 in Branch

[Carlo Poggiarelli]

Ok.

From attached  log I see that CME does not receive any response from Branch ip phone:

SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP <<HQ phone IP Address Removed>>:5060;branch=z9hG4bK370d0e1d

Can you please check the connectivity between sites.

Being private ip address, you can include on your debug

I you can, please post both HQ and Branch Config

Thanks

Regards

Carlo

[ahmed-hassan1110]

please find the same file again with the real IPs.

regarding the branch there is no any voice related config it is just 887 router configured with DMVPN to provide IP connectivity to the HQ.

moreover please find the 2nd file which have the debug voice ccapi and debug ccsip message outputs for a successful call from 8831 (SIP conference station, extension 110) in the HQ to 7821 (extension 201) in the branch, in which you will find the SIP invitation reply is being received normally and the call succeeded.

so if there is a connectivity issue or any type of FW blocking it should block calls coming from the 8831 station which doesn't happen? I'm just trying to think loudly with you.