03-03-2014 08:58 AM - edited 03-16-2019 09:59 PM
Good morning everyone!
I have a problem with a new deployment of CME that I'm hoping y'all can help me with. We're running CME 9.5 and using Exchange 2013 for voicemail and auto-attendant services. We have a SIP trunk for calls to and from the PSTN and then another trunk to Exchange 2013 for its UM services.
Currently I am unable to call in from the outside and reach any SIP destination from the PSTN. I have tried calling the DID when pointed to the voicemail pilot, the AA pilot, and a SIP DN on a softphone on the network. If I point the DID at a SCCP DN, the call completes without issue. I can also call out from the SIP softphone over the trunk to a SIP endpoint hanging off of our system here at my office.
The behavior of the failed call is the same whether the destination is Exchange or the SIP softphone. Basically I get a loop of SIP Invite, Trying, Moved Temporarily, and ACK until the call times out and goes busy. Below are the debugs from "debug ccsip messages" on these calls. I have also attached pertinent parts of the voice configuration from the router. Some names and numbers have been altered but otherwise this is what we are running.
The router is currently in production but the voice services have yet to be deployed as I'm waiting until I can get voicemail working to roll out the new phone system so I'm free to make any voice changes needed.
Any help/advise would be greatly appreciated.
This debug is for an inbound call on the Provider Trunk to the Auto Attendant Pilot
*Feb 28 21:53:57.509: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:XXXXXXXXXX@10.1.129.254:5060 SIP/2.0
Via: SIP/2.0/UDP 209.209.172.231:5060;branch=z9hG4bKa82dvo209gog57d4h690.1
From: <sip:ZZZZZZZZZZZ@172.16.6.171;user=phone>;tag=1639169081-1393620731871-
To: "Client"<sip:XXXXXXXXXX@SIPTrunkProvider.com>
Call-ID: BW155211871280214-2041632561@172.16.6.171
CSeq: 1025663984 INVITE
Contact: <sip:ZZZZZZZZZZ@209.209.172.231:5060;transport=udp>
Supported: 100rel
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: application/media_control+xml,application/sdp,multipart/mixed
Max-Forwards: 9
Content-Type: application/sdp
Content-Length: 280
v=0
o=Filler 1840125 1 IN IP4 209.209.172.231
s=-
c=IN IP4 209.209.172.231
t=0 0
m=audio 62230 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=bsoft: 1 image udptl t38
SIP: Trying to parse unsupported attribute at media level
*Feb 28 21:53:57.517: //34971/A8928C04B7FB/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 209.209.172.231:5060;branch=z9hG4bKa82dvo209gog57d4h690.1
From: <sip:ZZZZZZZZZZ@172.16.6.171;user=phone>;tag=1639169081-1393620731871-
To: "Client"<sip:XXXXXXXXXX@SIPTrunkProvider.com>
Date: Fri, 28 Feb 2014 21:53:57 GMT
Call-ID: BW155211871280214-2041632561@172.16.6.171
CSeq: 1025663984 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.3.2.T
Content-Length: 0
*Feb 28 21:53:57.517: //34971/A8928C04B7FB/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 209.209.172.231:5060;branch=z9hG4bKa82dvo209gog57d4h690.1
From: <sip:ZZZZZZZZZZ@172.16.6.171;user=phone>;tag=1639169081-1393620731871-
To: "Client"<sip:XXXXXXXXXX@SIPTrunkProvider.com>;tag=8FDC57C8-1C69
Date: Fri, 28 Feb 2014 21:53:57 GMT
Call-ID: BW155211871280214-2041632561@172.16.6.171
CSeq: 1025663984 INVITE
Allow-Events: telephone-event
Warning: 399 10.1.129.254 "Transcoder Not Configured"
Server: Cisco-SIPGateway/IOS-15.3.2.T
Reason: Q.850;cause=47
Content-Length: 0
*Feb 28 21:53:57.565: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:XXXXXXXXXX@10.1.129.254:5060 SIP/2.0
Via: SIP/2.0/UDP 209.209.172.231:5060;branch=z9hG4bKa82dvo209gog57d4h690.1
CSeq: 1025663984 ACK
From: <sip:ZZZZZZZZZZ@172.16.6.171;user=phone>;tag=1639169081-1393620731871-
To: "Client"<sip:XXXXXXXXXX@SIPTrunkProvider.com>;tag=8FDC57C8-1C69
Call-ID: BW155211871280214-2041632561@172.16.6.171
Max-Forwards: 9
Content-Length: 0
03-03-2014 11:01 AM
Hi,
Reason: Q.850;cause=47 indicates Codec mismatch. Please cross check all the Inbound & Outbound dialpeers and its Codec configuration.
What codec does your provider support?
03-03-2014 11:29 AM
On top of that... very clearly it also tried to use a transcoder but none was available. I agree, check regions in CUCM + all dial-peers on GW to ensure they are using the proper codec OR voice-class codec for the ability to switch as needed.
You could also hack and toss in a transcoder to be sure... not optimal though, you would rather have good codec matching if possible.
Feb 28 21:53:57.517: //34971/A8928C04B7FB/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 209.209.172.231:5060;branch=z9hG4bKa82dvo209gog57d4h690.1
From:
To: "Client"<>>XXXXXXXXXX@SIPTrunkProvider.com>;tag=8FDC57C8-1C69
Date: Fri, 28 Feb 2014 21:53:57 GMT
Call-ID: BW155211871280214-2041632561@172.16.6.171
CSeq: 1025663984 INVITE
Allow-Events: telephone-event
Warning: 399 10.1.129.254 "Transcoder Not Configured"
Server: Cisco-SIPGateway/IOS-15.3.2.T
Reason: Q.850;cause=47
Content-Length: 0
Chad
03-03-2014 11:46 AM
The codec issue is unrelated. I fixed it with the addition of the "voice-class codec 1" command on the SIP dial peers but the same thing happens when calling in
03-03-2014 09:02 PM
Please collect the below debugs for a test call.
- debug voice ccapi inout
- Debug ccsip message
03-04-2014 06:13 AM
The output of "Debug ccsip message" is above in the original post. The output has not changed with the exception of the codec and transcoder errors no longer being present. I have attached the output of "Debug voice ccapi inout" to the original post. Thank you.
09-12-2014 06:44 AM
Colin,
I just wanted to report that I was having the same issue and saw that when Exchange was sending the redirect from 5062 to 5065 that it was using the FQDN of Exchange instead of the IP address. I added a host record on the router for the name and everything worked fine after that.
03-06-2014 05:54 AM
Suresh,
I was mistaken about which debugs the ones above were. The above CCSIP debugs are from a call from the PSTN to a SIP softphone which are much less important than getting the connection to Exchange working. I have added debugs from a call to Exchange below as per your request. From what I can tell (Im still not very SIP savvy) The SIP conversation between the provider trunk and the router never completes before the SIP conversation between the inbound and Exchange starts. As I said I'm still getting familiar with SIP so maybe this is nothing but it looked a little odd to my eye. Debugs are below
INVITE sip:XXXXXXXXXX@10.1.129.254:5060 SIP/2.0
Via: SIP/2.0/UDP 209.209.172.231:5060;branch=z9hG4bKu4t4v03048p0061dc110.1
From:
To: "SW Child Dev"<>>XXXXXXXXXX@SIPTrunkProvider.com>
Call-ID: BW082417109060314-679806382@172.16.6.141
CSeq: 197684779 INVITE
Contact:
Supported: 100rel
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: application/media_control+xml,application/sdp,multipart/mixed
Max-Forwards: 9
Content-Type: application/sdp
Content-Length: 282
v=0
o=FillerRealm 111344245 1 IN IP4 209.209.172.231
s=-
c=IN IP4 209.209.172.231
t=0 0
m=audio 52898 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=bsoft: 1 image udptl t38
SIP: Trying to parse unsupported attribute at media level
Mar 6 13:25:51.801: //1439/AC26808287F1/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 209.209.172.231:5060;branch=z9hG4bKu4t4v03048p0061dc110.1
From:
To: "SW Child Dev"<>>XXXXXXXXXX@SIPTrunkProvider.com>
Date: Thu, 06 Mar 2014 13:25:51 GMT
Call-ID: BW082417109060314-679806382@172.16.6.141
CSeq: 197684779 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.3.2.T
Content-Length: 0
Mar 6 13:25:51.813: //1440/AC27B96A87F6/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:601@10.1.1.11:5062 SIP/2.0
Via: SIP/2.0/TCP 10.1.129.254:5060;branch=z9hG4bK5B61050
Remote-Party-ID:
From: <>>ZZZZZZZZZZ@SIPTrunkProvider.com>;tag=CBB8924-2203
To: <601>601>
Date: Thu, 06 Mar 2014 13:25:51 GMT
Call-ID: AC285592-A46911E3-87FAC945-249872F9@10.1.129.254
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2888284522-2758349283-2281097541-0613970681
User-Agent: Cisco-SIPGateway/IOS-15.3.2.T
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1394112351
Contact:
Diversion:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 8
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270
v=0
o=CiscoSystemsSIP-GW-UserAgent 5118 5186 IN IP4 10.1.129.254
s=SIP Call
c=IN IP4 10.1.129.254
t=0 0
m=audio 17346 RTP/AVP 18 101
c=IN IP4 10.1.129.254
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Mar 6 13:25:51.813: //1440/AC27B96A87F6/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
FROM: <>>ZZZZZZZZZZ@SIPTrunkProvider.com>;tag=CBB8924-2203
TO: <601>601>
CSEQ: 101 INVITE
CALL-ID: AC285592-A46911E3-87FAC945-249872F9@10.1.129.254
VIA: SIP/2.0/TCP 10.1.129.254:5060;branch=z9hG4bK5B61050
CONTENT-LENGTH: 0
TIMESTAMP: 1394112351
Mar 6 13:25:52.013: //1440/AC27B96A87F6/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 302 Moved Temporarily
FROM: <>>ZZZZZZZZZZ@SIPTrunkProvider.com>;tag=CBB8924-2203
TO: <601>;epid=9D14031D42;tag=38224e65e4601>
CSEQ: 101 INVITE
CALL-ID: AC285592-A46911E3-87FAC945-249872F9@10.1.129.254
VIA: SIP/2.0/TCP 10.1.129.254:5060;branch=z9hG4bK5B61050
CONTACT: <>>601@Exchange-UM.swcdcinc.org:5065;transport=Tcp>
CONTENT-LENGTH: 0
SERVER: RTCC/5.0.0.0
Diversion:
Mar 6 13:25:52.013: //1440/AC27B96A87F6/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:601@10.1.1.11:5062 SIP/2.0
Via: SIP/2.0/TCP 10.1.129.254:5060;branch=z9hG4bK5B61050
From: <>>ZZZZZZZZZZ@SIPTrunkProvider.com>;tag=CBB8924-2203
To: <601>;epid=9D14031D42;tag=38224e65e4601>
Date: Thu, 06 Mar 2014 13:25:51 GMT
Call-ID: AC285592-A46911E3-87FAC945-249872F9@10.1.129.254
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0
03-06-2014 06:47 AM
The call to 601 is negotiating G729 codec.
Sent:
INVITE sip:601@10.1.1.11:5062 SIP/2.0
Via: SIP/2.0/TCP 10.1.129.254:5060;branch=z9hG4bK5B61050
Remote-Party-ID:
From: <>ZZZZZZZZZZ@SIPTrunkProvider.com>;tag=CBB8924-2203>
To: <601>601>
Date: Thu, 06 Mar 2014 13:25:51 GMT
Call-ID: AC285592-A46911E3-87FAC945-249872F9@10.1.129.254
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2888284522-2758349283-2281097541-0613970681
User-Agent: Cisco-SIPGateway/IOS-15.3.2.T
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1394112351
Contact:
Diversion:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 8
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270
v=0
o=CiscoSystemsSIP-GW-UserAgent 5118 5186 IN IP4 10.1.129.254
s=SIP Call
c=IN IP4 10.1.129.254
t=0 0
m=audio 17346 RTP/AVP 18 101
c=IN IP4 10.1.129.254
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
!
could you please configure the voice class codec command on the dial-peer voice 1 and check the behaviour?
//Suresh
Please rate all the useful posts.
03-06-2014 09:10 AM
Suresh,
I have the voice class codec 1 command on the inbound dial peer and see no change in behavior.
03-06-2014 09:22 AM
Hi.
Please apply voice class codec to dialpeer 3 too and check the behaviour if is the same.
After that change please post a debug ccsip message again.
Thanks
Regards
Carlo
Please rate all helpful posts
"The more you help the more you learn"
03-06-2014 09:40 AM
Carlo,
Thank you for taking a look. I updated that dial-peer previously. The last debug ccsip messages I posted includes output with this applied to the dial-peer voice 3
03-06-2014 09:40 AM
Please collect the debug ccsip message and debug voice ccapi inout for a test call. Please collect these debugs together in the buffer and attach the files here.
Sent from Cisco Technical Support Android App
03-06-2014 09:46 AM
Most recent debugs are now attached as debugs.log
03-06-2014 10:44 AM
Hello,
we see the call is redirected to AA-601 from the dial-peer 3 with codec G711ulaw & G729 and destination port: 5062.
instead of getting 180/183, we are getting 302 Moved Temporarily from AA. could you please crosscheck if that number 601 is properly configured in AA?
Mar 6 17:42:54.917: //2286/94EC31A5954F/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 302 Moved Temporarily
FROM: <>>8282858882@morrisbroadband.com>;tag=DA6DECC-122A
TO: <601>;epid=9D14031D42;tag=bfa3d4b9c5601>
CSEQ: 101 INVITE
CALL-ID: 94ECCDCD-A48D11E3-9553C945-249872F9@10.1.129.254
VIA: SIP/2.0/TCP 10.1.129.254:5060;branch=z9hG4bK6CF1199
CONTACT: <>>601@Exchange-UM.swcdcinc.org:5065;transport=Tcp>
CONTENT-LENGTH: 0
SERVER: RTCC/5.0.0.0
Diversion: <8283540105>;privacy=off;reason=unconditional;counter=1;screen=no8283540105>
Also, the contact field of the above 302 message is showing the port number 5065, but in the dial-peer we have configured 5062 to AA. why is that difference?
//Suresh
Please rate all the useful posts.
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