07-13-2020 12:53 AM - edited 07-14-2020 05:30 AM
Wonder if you could help me out here, I'm currently setting up a new cube but hitting problems placing outgoing calls, incoming calls are working fine, if I place an outgoing call to my mobile number I get a message (I can hear it) Sorry the service you require can not be connected. Below you will find my running config stripped and a few debugs.
Debug ccsip call Jul 13 07:16:08.075: //96612/B2C67D800000/SIP/Call/sipSPICallInfo: The Call Setup Information is: Call Control Block (CCB) : 0x0x7F0626233170 State of The Call : STATE_DEAD TCP Sockets Used : NO Calling Number : 45000 Called Number : 07973xxxxxx Source IP Address (Sig ): 10.2.251.57 Destn SIP Req Addr:Port : 82.16.19.2:5060 Destn SIP Resp Addr:Port : 82.16.19.2:5060 Destination Name : 82.16.19.2 Jul 13 07:16:08.075: //96612/B2C67D800000/SIP/Call/sipSPIMediaCallInfo: Number of Media Streams: 1 Media Stream : 1 Negotiated Codec : g711alaw Negotiated Codec Bytes : 160 Nego. Codec payload : 8 (tx), 8 (rx) Negotiated Dtmf-relay : 6 Dtmf-relay Payload : 101 (tx), 101 (rx) Source IP Address (Media): 10.2.251.57 Source IP Port (Media): 8190 Destn IP Address (Media): 82.16.19.18 Destn IP Port (Media): 10100 Orig Destn IP Address:Port (Media): [ - ]:0 Jul 13 07:16:08.075: //96612/B2C67D800000/SIP/Call/sipSPICallInfo: Disconnect Cause (CC) : 16 Disconnect Cause (SIP) : 487 Jul 13 07:16:08.076: //96616/B2C67D800000/SIP/Call/sipSPICallInfo: The Call Setup Information is: Call Control Block (CCB) : 0x0x7F0626241C80 State of The Call : STATE_DEAD TCP Sockets Used : YES Calling Number : 45000 Called Number : 07973xxxxxx Source IP Address (Sig ): 10.2.251.57 Destn SIP Req Addr:Port : :0 Destn SIP Resp Addr:Port : :0 Destination Name : Jul 13 07:16:08.077: //96616/B2C67D800000/SIP/Call/sipSPIMediaCallInfo: Number of Media Streams: 1 Media Stream : 1 Negotiated Codec : No Codec Negotiated Codec Bytes : 0 Nego. Codec payload : 255 (tx), 255 (rx) Negotiated Dtmf-relay : 0 Dtmf-relay Payload : 0 (tx), 0 (rx) Source IP Address (Media): 10.2.251.57 Source IP Port (Media): 8192 Destn IP Address (Media): - Destn IP Port (Media): 0 Orig Destn IP Address:Port (Media): [ - ]:0 Jul 13 07:16:08.077: //96616/B2C67D800000/SIP/Call/sipSPICallInfo: Disconnect Cause (CC) : 188 Disconnect Cause (SIP) : 200 Jul 13 07:16:08.080: //96611/B2C67D800000/SIP/Call/sipSPICallInfo: The Call Setup Information is: Call Control Block (CCB) : 0x0x7F062621D0D8 State of The Call : STATE_DEAD TCP Sockets Used : YES Calling Number : 45000 Called Number : 07973xxxxxx Source IP Address (Sig ): 10.0.12.30 Destn SIP Req Addr:Port : 10.0.12.17:5060 Destn SIP Resp Addr:Port : 10.0.12.17:34867 Destination Name : 10.0.12.17 Jul 13 07:16:08.080: //96611/B2C67D800000/SIP/Call/sipSPIMediaCallInfo: Number of Media Streams: 1 Media Stream : 1 Negotiated Codec : g711alaw Negotiated Codec Bytes : 160 Nego. Codec payload : 8 (tx), 8 (rx) Negotiated Dtmf-relay : 6 Dtmf-relay Payload : 101 (tx), 101 (rx) Source IP Address (Media): 10.0.12.30 Source IP Port (Media): 8188 Destn IP Address (Media): 172.30.152.11 Destn IP Port (Media): 32362 Orig Destn IP Address:Port (Media): [ - ]:0 Jul 13 07:16:08.080: //96611/B2C67D800000/SIP/Call/sipSPICallInfo: Disconnect Cause (CC) : 38 Disconnect Cause (SIP) : 503
Debug ccsip message Jul 13 07:10:30.638: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:07973xxxxxx@10.0.12.30:5060 SIP/2.0 Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eead65cae8f3 From: "VM SIP TEST 2" <sip:45000@10.0.12.17>;tag=404459~9c2c55f8-f6da-4001-942f-f8cb268e11d0-49787915 To: <sip:0797xxxxxx@10.0.12.30> Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b0f-110c000a@10.0.12.17 Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 User-Agent: Cisco-CUCM11.5 Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY CSeq: 101 INVITE Expires: 180 Allow-Events: presence Supported: X-cisco-srtp-fallback,X-cisco-original-called Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=VIDEO_UNSPECIFIED Session-ID: 30bca1117401e23b8117f8034def3ba0;remote=00000000000000000000000000000000 Cisco-Guid: 3994320000-0000065536-0000004169-0285999114 Session-Expires: 1800 P-Asserted-Identity: "VM SIP TEST 2" <sip:45000@10.0.12.17> Contact: <sip:45000@10.0.12.17:5060;transport=tcp> Max-Forwards: 70 Content-Length: 0 Jul 13 07:10:30.642: //96514/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 100 Trying Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eead65cae8f3 From: "VM SIP TEST 2" <sip:45000@10.0.12.17>;tag=404459~9c2c55f8-f6da-4001-942f-f8cb268e11d0-49787915 To: <sip:07973xxxxxx@10.0.12.30> Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b0f-110c000a@10.0.12.17 CSeq: 101 INVITE Allow-Events: kpml, telephone-event Server: Cisco-SIPGateway/IOS-16.6.6 Session-ID: 00000000000000000000000000000000;remote=30bca1117401e23b8117f8034def3ba0 Content-Length: 0 Jul 13 07:10:30.645: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:07973xxxxxx@82.16.19.2:5060 SIP/2.0 Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12084228B From: "VM SIP TEST 2" <sip:45000@10.2.251.57>;tag=14803119-1814 To: <sip:07973xxxxxx@82.16.19.2> Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 Supported: 100rel,timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Cisco-Guid: 3994320000-0000065536-0000004169-0285999114 User-Agent: Cisco-SIPGateway/IOS-16.6.6 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1594624230 Contact: <sip:45000@10.2.251.57:5060> Expires: 180 Allow-Events: telephone-event Max-Forwards: 69 P-Asserted-Identity: "VM SIP TEST 2" <sip:45000@10.2.251.57> Session-ID: 30bca1117401e23b8117f8034def3ba0;remote=00000000000000000000000000000000 Session-Expires: 1800 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 243 v=0 o=CiscoSystemsSIP-GW-UserAgent 1948 8484 IN IP4 10.2.251.57 s=SIP Call c=IN IP4 10.2.251.57 t=0 0 m=audio 8184 RTP/AVP 8 101 c=IN IP4 10.2.251.57 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Jul 13 07:10:30.649: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: OPTIONS sip:10.0.12.30:5060 SIP/2.0 Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eeae2d555626 From: <sip:10.0.12.17>;tag=524611185 To: <sip:10.0.12.30> Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b10-110c000a@10.0.12.17 User-Agent: Cisco-CUCM11.5 CSeq: 101 OPTIONS Contact: <sip:10.0.12.17:5060;transport=tcp> Max-Forwards: 0 Content-Length: 0 Jul 13 07:10:30.651: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eeae2d555626 From: <sip:10.0.12.17>;tag=524611185 To: <sip:10.0.12.30>;tag=1480311F-2001 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b10-110c000a@10.0.12.17 Server: Cisco-SIPGateway/IOS-16.6.6 CSeq: 101 OPTIONS Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: kpml, telephone-event Accept: application/sdp Supported: 100rel,timer,resource-priority,replaces,sdp-anat Content-Type: application/sdp Content-Length: 163 v=0 o=CiscoSystemsSIP-GW-UserAgent 8832 2086 IN IP4 10.0.12.30 s=SIP Call c=IN IP4 10.0.12.30 t=0 0 m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3 c=IN IP4 10.0.12.30 Jul 13 07:10:30.654: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12084228B From: "VM SIP TEST 2" <sip:45000@10.2.251.57>;tag=14803119-1814 To: <sip:07973xxxxxx@82.16.19.2> Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 CSeq: 101 INVITE Timestamp: 1594624230 Content-Length: 0 Jul 13 07:10:30.662: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12084228B Proxy-Authenticate: Digest realm="Realm",nonce="MTU5NDYyMDIyMTg3NjU3ZTRlZGJjZTRiNTdlYjQ4OGU5NTFiMzQyY2Q1Yzc5",stale=false,algorithm=MD5,qop="auth" To: <sip:07973xxxxxx@82.16.19.2>;tag=3803613030-698069643 From: "VM SIP TEST 2" <sip:45000@10.2.251.57;user=phone>;tag=14803119-1814 Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 CSeq: 101 INVITE Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL Contact: <sip:07973xxxxxx@82.16.19.2:5060> Content-Length: 0 Jul 13 07:10:30.663: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:07973xxxxxx@82.16.19.2:5060 SIP/2.0 Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12084228B From: "VM SIP TEST 2" <sip:45000@10.2.251.57>;tag=14803119-1814 To: <sip:07973xxxxxx@82.16.19.2>;tag=3803613030-698069643 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: telephone-event Session-ID: ;remote= Content-Length: 0 Jul 13 07:10:30.664: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:07973xxxxxx@82.16.19.2:5060 SIP/2.0 Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12085A0C From: "VM SIP TEST 2" <sip:45000@10.2.251.57>;tag=14803119-1814 To: <sip:07973xxxxxx@82.16.19.2> Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 Supported: 100rel,timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Cisco-Guid: 3994320000-0000065536-0000004169-0285999114 User-Agent: Cisco-SIPGateway/IOS-16.6.6 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 102 INVITE Timestamp: 1594624230 Contact: <sip:45000@10.2.251.57:5060> Expires: 180 Allow-Events: telephone-event Proxy-Authorization: Digest username="onboard09",realm="Realm",uri="sip:07973xxxxxx@82.16.19.2:5060",response="ad85f4c9c9878a2375cec50674659789",nonce="MTU5NDYyMDIyMTg3NjU3ZTRlZGJjZTRiNTdlYjQ4OGU5NTFiMzQyY2Q1Yzc5",cnonce="E6D38045",qop=auth,algorithm=MD5,nc=00000001 Max-Forwards: 69 P-Asserted-Identity: "VM SIP TEST 2" <sip:45000@10.2.251.57> Session-ID: 30bca1117401e23b8117f8034def3ba0;remote=00000000000000000000000000000000 Session-Expires: 1800 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 243 v=0 o=CiscoSystemsSIP-GW-UserAgent 1948 8484 IN IP4 10.2.251.57 s=SIP Call c=IN IP4 10.2.251.57 t=0 0 m=audio 8184 RTP/AVP 8 101 c=IN IP4 10.2.251.57 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Jul 13 07:10:30.673: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12085A0C From: "VM SIP TEST 2" <sip:45000@10.2.251.57>;tag=14803119-1814 To: <sip:07973xxxxxx@82.16.19.2> Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 CSeq: 102 INVITE Timestamp: 1594624230 Content-Length: 0 Jul 13 07:10:30.725: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12085A0C To: <sip:07973xxxxxx@82.16.19.2>;tag=3803613030-1020988772 From: "VM SIP TEST 2" <sip:45000@10.2.251.57;user=phone>;tag=14803119-1814 Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 CSeq: 102 INVITE Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL Contact: <sip:07973xxxxxx@82.16.19.2:5060> Content-Type: application/sdp Content-Length: 252 v=0 o=brnt-voiponboardsbc1-a 201206121 201206121 IN IP4 82.16.19.2 s=sip call c=IN IP4 82.16.19.18 t=0 0 m=audio 10098 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=silenceSupp:off - - - - Jul 13 07:10:30.728: //96514/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 183 Session Progress Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eead65cae8f3 From: "VM SIP TEST 2" <sip:45000@10.0.12.17>;tag=404459~9c2c55f8-f6da-4001-942f-f8cb268e11d0-49787915 To: <sip:07973xxxxxx@10.0.12.30>;tag=1480316D-1AD7 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b0f-110c000a@10.0.12.17 CSeq: 101 INVITE Require: 100rel RSeq: 8573 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: kpml, telephone-event Contact: <sip:07973xxxxxx@10.0.12.30:5060;transport=tcp> Supported: sdp-anat Server: Cisco-SIPGateway/IOS-16.6.6 Session-ID: 58d9216120e7570f97bc8825f965a0f7;remote=30bca1117401e23b8117f8034def3ba0 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 240 v=0 o=CiscoSystemsSIP-GW-UserAgent 3781 3104 IN IP4 10.0.12.30 s=SIP Call c=IN IP4 10.0.12.30 t=0 0 m=audio 8182 RTP/AVP 8 101 c=IN IP4 10.0.12.30 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 Jul 13 07:10:30.793: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: PRACK sip:07973xxxxxx@10.0.12.30:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eeaf1d80c380 From: "VM SIP TEST 2" <sip:45000@10.0.12.17>;tag=404459~9c2c55f8-f6da-4001-942f-f8cb268e11d0-49787915 To: <sip:07973xxxxxx@10.0.12.30>;tag=1480316D-1AD7 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b0f-110c000a@10.0.12.17 User-Agent: Cisco-CUCM11.5 CSeq: 102 PRACK RAck: 8573 101 INVITE Allow-Events: presence Max-Forwards: 70 Content-Type: application/sdp Content-Length: 245 v=0 o=CiscoSystemsCCM-SIP 404459 1 IN IP4 10.0.12.17 s=SIP Call c=IN IP4 172.30.152.11 b=TIAS:64000 b=CT:64 b=AS:64 t=0 0 m=audio 32116 RTP/AVP 8 101 a=ptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Jul 13 07:10:30.796: //96514/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eeaf1d80c380 From: "VM SIP TEST 2" <sip:45000@10.0.12.17>;tag=404459~9c2c55f8-f6da-4001-942f-f8cb268e11d0-49787915 To: <sip:07973xxxxxx@10.0.12.30>;tag=1480316D-1AD7 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b0f-110c000a@10.0.12.17 Server: Cisco-SIPGateway/IOS-16.6.6 CSeq: 102 PRACK Session-ID: 58d9216120e7570f97bc8825f965a0f7;remote=30bca1117401e23b8117f8034def3ba0 Content-Length: 0 Jul 13 07:10:31.209: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: OPTIONS sip:10.0.12.30:5060 SIP/2.0 Via: SIP/2.0/TCP 10.0.12.16:5060;branch=z9hG4bK6bae22f24ecca From: <sip:10.0.12.16>;tag=2084978717 To: <sip:10.0.12.30> Date: Mon, 13 Jul 2020 07:10:31 GMT Call-ID: eead1300-f0c108e7-4aa6e-100c000a@10.0.12.16 User-Agent: Cisco-CUCM11.5 CSeq: 101 OPTIONS Contact: <sip:10.0.12.16:5060;transport=tcp> Max-Forwards: 0 Content-Length: 0 Jul 13 07:10:31.211: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/TCP 10.0.12.16:5060;branch=z9hG4bK6bae22f24ecca From: <sip:10.0.12.16>;tag=2084978717 To: <sip:10.0.12.30>;tag=14803350-A2F Date: Mon, 13 Jul 2020 07:10:31 GMT Call-ID: eead1300-f0c108e7-4aa6e-100c000a@10.0.12.16 Server: Cisco-SIPGateway/IOS-16.6.6 CSeq: 101 OPTIONS Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: kpml, telephone-event Accept: application/sdp Supported: 100rel,timer,resource-priority,replaces,sdp-anat Content-Type: application/sdp Content-Length: 163 v=0 o=CiscoSystemsSIP-GW-UserAgent 4174 9701 IN IP4 10.0.12.30 s=SIP Call c=IN IP4 10.0.12.30 t=0 0 m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3 c=IN IP4 10.0.12.30 Jul 13 07:10:37.860: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12085A0C To: <sip:0797xxxxxx@82.16.19.2>;tag=3803613030-1020988772 From: "VM SIP TEST 2" <sip:45000@10.2.251.57;user=phone>;tag=14803119-1814 Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 CSeq: 102 INVITE Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL Contact: <sip:07973xxxxxx@82.16.19.2:5060> Content-Length: 0 Jul 13 07:10:37.862: //96515/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:07973xxxxxx@82.16.19.2:5060 SIP/2.0 Via: SIP/2.0/UDP 10.2.251.57:5060;branch=z9hG4bK12085A0C From: "VM SIP TEST 2" <sip:45000@10.2.251.57>;tag=14803119-1814 To: <sip:07973xxxxxx@82.16.19.2>;tag=3803613030-1020988772 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: C544F9D6-C40E11EA-B9A3B5A2-101A3230@10.2.251.57 Max-Forwards: 70 CSeq: 102 ACK Allow-Events: telephone-event Content-Length: 0 Jul 13 07:10:37.865: //96514/EE147C800000/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 503 Service Unavailable Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eead65cae8f3 From: "VM SIP TEST 2" <sip:45000@10.0.12.17>;tag=404459~9c2c55f8-f6da-4001-942f-f8cb268e11d0-49787915 To: <sip:07973xxxxxx@10.0.12.30>;tag=1480316D-1AD7 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b0f-110c000a@10.0.12.17 CSeq: 101 INVITE Allow-Events: kpml, telephone-event Server: Cisco-SIPGateway/IOS-16.6.6 Reason: Q.850;cause=0 Session-ID: 58d9216120e7570f97bc8825f965a0f7;remote=30bca1117401e23b8117f8034def3ba0 Session-Expires: 1800 Content-Length: 0 Jul 13 07:10:37.867: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: ACK sip:07973xxxxxx@10.0.12.30:5060 SIP/2.0 Via: SIP/2.0/TCP 10.0.12.17:5060;branch=z9hG4bK1eead65cae8f3 From: "VM SIP TEST 2" <sip:45000@10.0.12.17>;tag=404459~9c2c55f8-f6da-4001-942f-f8cb268e11d0-49787915 To: <sip:07973xxxxxx@10.0.12.30>;tag=1480316D-1AD7 Date: Mon, 13 Jul 2020 07:10:30 GMT Call-ID: ee147c80-f0c108e6-15b0f-110c000a@10.0.12.17 User-Agent: Cisco-CUCM11.5 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: presence Content-Length: 0
Debug ccisp error SIP: (96454) Group (a= group line) attribute, level 65535 instance 1 not found. SIP: (96454) Group (a= group line) attribute, level 65535 instance 1 not found. SIP: (96454) Group (a= group line) attribute, level 65535 instance 1 not found. SIP: (96454) Group (a= group line) attribute, level 65535 instance 1 not found. SIP: Attribute mid, level 1 instance 1 not found. SIP: setup attribute, level 1 instance 1 not found. SIP: connection attribute, level 1 instance 1 not found. SIP: Attribute label, level 1 instance 1 not found. SIP: a=framerate attribute, level 1 instance 1 not found. Jul 13 07:07:03.183: //-1/xxxxxxxxxxxx/SIP/Error/voipCodec_to_rtpAvpCodec: Unexpected VoIPCodec Type :No Codec SIP: (96453) Group (a= group line) attribute, level 65535 instance 1 not found. SIP: (96453) Group (a= group line) attribute, level 65535 instance 1 not found. Jul 13 07:07:03.184: //96454/72B2CB000000/SIP/Error/sipSPIGetNewLocalMediaDirection: Unknown media direction (0) from remote end SIP: (96453) Group (a= group line) attribute, level 65535 instance 1 not found. Jul 13 07:07:03.225: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free: Freeing NULL pointer! SIP: Attribute mid, level 1 instance 1 not found. Jul 13 07:07:03.227: //96453/72B2CB000000/SIP/Error/sipSPIGetNewLocalMediaDirection: Unknown media direction (0) from remote end SIP: setup attribute, level 1 instance 1 not found. SIP: connection attribute, level 1 instance 1 not found. SIP: Attribute label, level 1 instance 1 not found. SIP: a=framerate attribute, level 1 instance 1 not found. Jul 13 07:07:10.158: //96453/72B2CB000000/SIP/Error/sipSPIFlushDeferredQueue: Invalid deferredQueue Jul 13 07:07:10.165: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIRemoveBranchName: invalid ccb, bName or branch list for sipSPIRemoveBranchName Jul 13 07:07:10.169: //-1/xxxxxxxxxxxx/SIP/Error/ccsip_iwf_process_event: Dead CCB Jul 13 07:07:10.169: //96454/72B2CB000000/SIP/Error/ccsip_offer_ans_md_invite_ack_answer_sent_hdlr: Unable to send ACK sent peer event
And finally my running config
no voice hunt unassigned-number no voice hunt no-response no voice hunt dest-out-of-order no voice hunt invalid-number voice call send-alert voice rtp send-recv ! voice service voip mode border-element license capacity 200 allow-connections sip to sip redirect ip2ip fax protocol pass-through g711alaw sip session refresh header-passing subscription maximum originate 2 asserted-id pai privacy pstn options-ping 60 no update-callerid early-offer forced midcall-signaling passthru privacy-policy passthru ! ! voice class e164-pattern-map 9 description *** PSTN Numbers Outbound *** e164 +800T e164 +44T e164 ^1800[01]$ e164 ^999$ e164 ^11[68]...$ e164 ^1..$ e164 ^[01]T e164 ^[02]T e164 ^[2]T ! ! voice class dpg 90 description *** SBC DPG *** dial-peer 90 preference 1 dial-peer 91 preference 2 ! voice class dpg 1000 description *** CUCM DPG *** dial-peer 1000 preference 1 dial-peer 1001 preference 2 ! voice class sip-options-keepalive 1 description ** global options pings settings ** up-interval 30 retry 3 transport udp ! voice translation-rule 1 rule 1 /^\([127-9]......\)$/ /0115\1/ ! ! voice translation-profile BlockedNumbers translate calling 777 ! voice translation-profile OutboundCalledPartyforShortDIAL translate called 1 ! interface GigabitEthernet0/0/0 ip address 10.2.251.57 255.255.255.252 no ip redirects no ip proxy-arp media-type rj45 negotiation auto ! interface GigabitEthernet0/0/1 ip address 10.0.12.30 255.255.255.0 no ip redirects no ip proxy-arp negotiation auto ! ! mgcp behavior rsip-range tgcp-only mgcp behavior comedia-role none mgcp behavior comedia-check-media-src disable mgcp behavior comedia-sdp-force disable ! mgcp profile default ! ! ! ! dial-peer voice 9 voip description ** INBOUND Dial-Peer from SIP Platform ** translation-profile incoming BlockedNumbers call-block disconnect-cause incoming unassigned-number session protocol sipv2 session transport udp destination dpg 1000 incoming uri via ITSP voice-class codec 1 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte ip qos dscp cs3 signaling no vad ! dial-peer voice 10 voip description *** CUCM to CUBE (inbound) *** translation-profile incoming OutboundCalledPartyforShortDIAL session protocol sipv2 session transport tcp destination dpg 90 incoming uri via CUCM voice-class codec 1 voice-class sip bind control source-interface GigabitEthernet0/0/1 voice-class sip bind media source-interface GigabitEthernet0/0/1 dtmf-relay rtp-nte sip-kpml no vad ! dial-peer voice 1000 voip description *** CUBE to CUCM LOX-SUB 1 (outbound) *** preference 1 destination-pattern 69... session protocol sipv2 session target ipv4:10.0.12.17 session transport tcp voice-class sip options-keepalive profile 1 voice-class sip bind control source-interface GigabitEthernet0/0/1 voice-class sip bind media source-interface GigabitEthernet0/0/1 dtmf-relay rtp-nte sip-kpml codec g711alaw ip qos dscp cs3 signaling no vad ! dial-peer voice 90 voip description *** SBC3 Birmingham - Preferred Route *** preference 1 destination-pattern .T session protocol sipv2 session target ipv4:xx.xx.xx.xx session transport udp voice-class sip options-ping 60 voice-class sip options-keepalive retry 3 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte dtmf-interworking rtp-nte codec g711alaw ip qos dscp cs3 signaling no vad ! dial-peer voice 1001 voip description *** CUBE to CUCM WTG-SUB 1(outbound) *** preference 2 destination-pattern 69... session protocol sipv2 session target ipv4:SUBSCRIBER session transport tcp voice-class sip options-keepalive profile 1 voice-class sip bind control source-interface GigabitEthernet0/0/1 voice-class sip bind media source-interface GigabitEthernet0/0/1 dtmf-relay rtp-nte sip-kpml codec g711alaw ip qos dscp cs3 signaling no vad ! dial-peer voice 1002 voip description *** CUBE to CUCM PUB (outbound) *** preference 3 destination-pattern 69... session protocol sipv2 session target ipv4:PUBLISHER session transport tcp voice-class sip options-keepalive profile 1 voice-class sip bind control source-interface GigabitEthernet0/0/1 voice-class sip bind media source-interface GigabitEthernet0/0/1 dtmf-relay rtp-nte sip-kpml codec g711alaw ip qos dscp cs3 signaling no vad ! ! dial-peer hunt 1 sip-ua authentication username XXXXX password 7 XXXXX no remote-party-id aaa username proxy-auth retry invite 4 timers options 600 reason-header override connection-reuse
Thanks in advance
Martyn
07-15-2020 01:54 AM
If I call my mobile from the office, I see exactly that same sequence. We receive 183/SDP from the carrier but we don't get 200 OK until the call is answered. If I just let it ring I hear inband ringback. Hears an example where I let it ring for a bit then cancel from the caller's side. Like the example posted the 183/SDP has "Require: 100rel" and "RSeq: 5344" on the message sent to CUCM, but not the message received from the ITSP.
So I really think that sequence is OK, and the fact that he hears the message saying that the call can't be placed also suggests the same. The audio/RTP path must in fact be established. Unless the message is a CUCM one, but it doesn't sound that way.
In this screenshot I've cropped the address off the top but from left to right they are CUCM, CUBE Inside, CUBE Outside and ITSP Proxy.
07-15-2020 02:12 AM
Thanks, are you using the same call flow diagram as Ayodeji Okanlawon, if so what's the name of it?
Thanks
07-15-2020 02:47 AM
"TranslatorX" https://translatorx.org/
Free download and can read and filter various sorts of debugs, and also CUCM traces. Very easy to use.
07-15-2020 04:07 AM - edited 07-15-2020 04:17 AM
No the sequence is not okay. SIP does not work the way you have described..
For media to be established in SIP, a final response must be sent. For a successful call, that would be a 200 OK
SIP is an Offer/Answer Model and in this flow, here a view of what is going on...
++
1. CUBE sends INVITE with Offer to ITSP
2. ITSP sends an answer With 183 SDP ( Offer/Answer completed here )
to complette the exchange ITSP must send 200 OK
3. CUBE sends OFFER with 183 SDP to CUCM ( offer contains all the SDP received from ITSP)
4. CUCM sends Answer in PRACK to CUBE ( offer/answer model complete also)
++
Based on SIP RFC:
https://tools.ietf.org/html/draft-rosenberg-sip-early-media-00
Current implementations support early media through the 183 response code, which was first described in a now-expired Internet Draft. When the called party wishes to send early media to the caller, the called party sends a 183 response to the caller. That response contains SDP. When the caller receives the 183, it suppresses any local alerting of the user (for example, audible ringtones or a pop-up window), and begins playing out media that it receives. The SDP in the 183 provides an address to which RTCP packets can be sent.
If the call is ultimately rejected, the called party generates a non-2xx final response
However, if the call is accepted, the called party generates a 2xx (generally, with the same SDP as was present in the 183), and sends that to the caller. Media transmission continues as before.
NB: That media starts playing at the 183 SDP ( But 200 OK) must follow to complete the transaction/dialog
So in this case, the lack of 200 OK is the issue here...
And I have so many logs showing 200 OK followed by 183 Session progress, this is the right sequence
NB: the 487 received is also a valid response. This is the final response to the SIP INVITE and a 487 is valid however this may not be what is expected here. So the ONUS is on the ITSP to explain why a 487 is sent in stead of a 200 OK
07-15-2020 05:04 AM
@Ayodeji Okanlawon wrote:No the sequence is not okay. SIP does not work the way you have described..
For media to be established in SIP, a final response must be sent. For a successful call, that would be a 200 OK
I can only restate that in the example I posted audio was established following the 183/SDP, with no 200 OK received. The attached screenshot is from another gateway where I grabbed a Wireshark so as well hearing ringback, I can see the RTP in the capture and indeed play it back. That is from a customer installation so I would have to blank out quite a bit before posting any more detail, but please let me know if you would like me to do that. To summarise the RTP started immediately after 183/SDP, indeed it was the very next packet in the capture, and continued unbroken when 200 OK was received a few seconds later when the call was picked up.
The behaviour may well vary between providers, and maybe with CUBE configuration as well. I have seen traces where 183/SDP was followed by PRAC and then OK, although in that case the OK was a response to the PRACK and not to the Invite.
I have also seen cases where an inband announcement for call failure has been sent following an OK for the Invite - unhelpful as the call appears to have completed normally when you just look at the SIP.
07-15-2020 08:14 AM
This call flow you posted is the right one.
When we get 183 with SDP, media flows immediately however 200 OK must still follow for a normal call to proceed. That is the final response to the INVITE. In all cases regardless of ITSP, this is by the book ie RFC.
In cases where you don't get 200 OK, you must still get a final response ie 487. And its totally possible to play an announcement using 183 with SDP, followed by a 487...
I can only assume that you didn't wait long enough for the 200 OK Or something else is going on..
07-15-2020 08:23 AM
@Ayodeji Okanlawon wrote:This call flow you posted is the right one.
<snip>
I can only assume that you didn't wait long enough for the 200 OK Or something else is going on..
Sounds like we're in agreement, which is good. And yes in that first trace I deliberately did not wait too long but cancelled before the call connected, purely to demonstrate two way RTP without a 200 OK.
07-15-2020 06:39 AM
Hi all, this is the response from the ITSP, they are placing the issues firmly on our side.
Thanks
You do not set up an RTP stream, and the lack of that is what kills the call
“our 183 indicates that we want early media” – not strictly correct.
Your INVITE with SDP indicates that YOU want early media, which our 183 “agrees” with.
The issue is no RTP steam from yourself
07-15-2020 08:18 AM
@martynch1 wrote:“our 183 indicates that we want early media” – not strictly correct.
Your INVITE with SDP indicates that YOU want early media, which our 183 “agrees” with.
They're correct regarding 183. The 183 response, with SDP, is an example of "Early Media" meaning audio is carried before the call connects.
Can you just fully confirm that the "Sorry the service you require can not be connected" message is heard at the caller's end, ie on your CUCM phone? If so then clearly RTP of some sort is indeed passing. You may have to resort to a Wireshark capture to prove it if they are as obstinate as some providers.
The second line is incorrect. INVITE with SDP is "Early Offer", not the same as Early Media. Early Offer means the call's audio parameters are included in the initial Invite rather than provided later only when the call connects (Delayed Offer). You Invite from CUCM to the gateway, the first Invite in your debug, is Delayed Offer.
Delayed Offer does not prevent Early Media. Again in your debug your CUCM Invite is DO, no SDP included. Then CUCM receives the 183/SDP (Early Media) and responds with PRACK to provide its SDP.
07-15-2020 09:51 AM
Just like @TONY SMITH has mentioned, if you hear prompt about the service, then there is media passing through. Take a packet capture from CUBE send it over. Escalate the issue. Most times you are dealing with leve1/level 2 engineers who do not know the complexity of SIP solution.
in your packet capture you should see media flowing through after you receive 183 Session progress from ITSP
07-16-2020 03:38 AM
Hi guys, sorry for the delay, please find attached my trace from the cube, I've filtered on tcp any eq 5060 - hope that's ok.
I will step through myself to try and look into the issue, I see that we are now getting a 500 internal error, now sure why or if it's our 3rd party maintainers have been looking at this too for us as we have a ticket raised with them.
Looking forward to your thoughts as I'm gaining quite a bit of new knowledge here, thanks all.
Martyn
07-16-2020 06:58 AM
You will need to refine your filtering as that capture only shows packets from 10.012.30 to 10.0.12.17, which I think is your CUBE to your CUCM. It doesn't even show the reply.
Filtering for TCP port 5060 will only show SIP signalling, and only if it uses TCP. Your ITSP dial peers are specifically configured for UDP. In any case you want to see the RTP as well as the signalling, which is UDP but with dynamically chosen port numbers.
Now you've got the packet capture at least working, I'd suggest filtering for anything going between your CUBE and the ITSP end point.
By the way that 500 error sent back to Callmanager is not necessarily a different symptom. It's probably just the CUBE's way of telling CUCM that it's received an error from the provider.
I think we need to concentrate on the CUBE <> ITSP leg.
07-20-2020 12:10 AM
Well Thursday afternoon and all of Friday was wiped out because we had our 3rd party maintainers trying to help us out, its a service we do pay or after all, wasted two day as we have gone backwards, we now can not receive calls never mind make them, our test bed as now closed. We got close at one point when they put the full e164 on the phone itself, we could make an outgoing call, answer it and have a conversation, soon after that when they had played with out CUCM and cube - Nothing!
Here are my traces from the cube both outgoing and incoming, not sure if it shows where we are failing, today I will mostly be checking the configs before they were changed to see if I can get back to where we were on Thursday.
We are now struggling because we don't have the ITSP test bed to use.
Thanks all for your support
Martyn
07-20-2020 03:22 AM
Your captures still only show conversation between CUCM and your CUBE. We really need to see the conversation between CUBE and ITSP as well.
However looking at what you say, and your "outbound-working" capture it looks like the main difference is your calling number, which was an internal number "45000" in all the failed call examples, but "+441158045000" in your working example.
You say your maintainer did this by putting E164 number as the actual DN in CUCM. Of course that's one way to do it, but not necessarily the best way.
Can you tell us a bit more about your numbering plan and the CUCM configuration? Making a wild guess the most common practice would be to have the internal number "45000" as the DN, external number mask converting that to the most commonly used national format for the location (for example mask of "011580XXXXX" would convert to "01158045000").
If your ITSP wants numbers in E164 format you also have the option of converting with a voice translation rule on the gateway itself. We can help you with that.
07-22-2020 08:06 AM
Hi all, thanks for the replies and sorry fro my delay in responding, our test bed was taken off line by our ITSP so unable to peruse this right now, we've asked them for an extension to testing and if approved I will get a full capture over to you.
Regards
Martyn
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide