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-06-2014 10:49 AM
Suresh,
The AA is working properly, I can get to it from internal SCCP DNs.
That moved temporarily is due to Exchange. Connections are established on port 5062 but after the initial setup the port is changed to either 5065 or 5067 for the remainder of the call
03-06-2014 12:01 PM
After further testing the issue appears to be that the CME is not honoring the port redirect from 5062 to 5065 that comes from Exchange. If I point the SIP trunk directly at to port 5065 the call completes normally. I am unsure why CME would honor the redirect on calls from SCCP phone but not calls from a SIP origin.
The issue with having the trunk pointed at 5065 is that eventually Exchange will recycle the UMWorker process and then the port it tries to redirect to will change to 5067. I can probably get around this by forcing a restart of the UM service via script but would much prefer this work as intended with SIP calls.
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