[cisco-voip] 7821 phones issue

Wed Oct 28 11:42:44 EDT 2015

In the non-working Invite, CME is sending an Authorization header that
doesn't exist in the working case:
Authorization: Digest username="204",realm="all",uri="sip:201 at 10.10.3.2
;user=phone",response="13d0e80e52a41bc8642290d5744ca66d",nonce="9D2BD5F30012BAFA",cnonce="570b883d",qop=auth,nc=00000003,algorithm=MD5

This is forwarded from the incoming Invite from the 7821.  I'm guessing you
have some sort of header-passthrough configured here resulting in the
problem occurring.

On Wed, Oct 28, 2015 at 8:07 AM, Ahmed Abd EL-Rahman <
Ahmed.Rahman at bmbgroup.com> wrote:

> I know that there is a lack of a response to the SIP invite message which
> is being sent from HQ 7821 phone to the branch 7821 phone during the call
> setup which may point to a network connectivity (or blocking) in the
> middle, but can anyone give me a reasonable answer for why the same
> messages are flowing normally when the 8831 HQ phone initiate the call to
> the 7821 branch phone ?? if something blocked it will be blocked for all.
>
>
>
>
>
>
>
> Best Regards
>
>
>
> Ahmed Abd EL-Rahman
>
> Senior Network Engineer - KSA
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Ahmed Abd EL-Rahman
> *Sent:* Wednesday, October 28, 2015 3:02 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] 7821 phones issue
>
>
>
> 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 and can also call each others’ in
> the branch normally.
>
> - The issue is that *HQ* 7821 & 7861 phones *cannot* call 7821 *branch* phones
> (no ring back is heard 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:
>
>
>
>
> Also please find the debug ccsip message output for both successful call
> and unsuccessful call attached.
>
>
>
> So any ideas please ?
>
>
>
>
>
>
>
>
>
> Best Regards
>
>
>
> Ahmed Abd EL-Rahman
>
> Senior Network Engineer - KSA
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20151028/a69f78f5/attachment.html>