That did not go as planned. Doubt started to cripple down my spine.
It has to work I kept mumbling to myself, but ITSP and Cisco CUBE would hear none of it, numerous times..
Edit: I recommended using the CUBE Config Utility in conjunction with this post
SIP doesn’t usually stress me out anymore and after a dozen of expressway implementation neither does NATed VOIP. But apparently Murphy always keeps another trick up his sleeve.
The topology was pretty straight forward. Cisco CUBE was in a DMZ, behind an Internet facing FW which was doing the NAT for us.
Cisco CUBE: An unknown identity
It started off with a loud squeak, a sign of what’s about to come..
I set up the SIP Trunk from CUCM towards Cisco CUBE and from Cisco CUBE towards ITSP (Internet Telephony Service Provider) and tried to call.
First try, no luck.
Went over my configuration again. All checked out fine.
The first setback came early in the game forcing me to look under the hood.
*I didn’t want to use the customer logs so I replicated the issues in my own environment.
Debug ccsip messagesThe outcome was similar to this:
Sent:
INVITE sip:pashat@iptel.org:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK2C21C6
Remote-Party-ID: "ucpros" <sip:1505@192.168.1.20>;party=calling;screen=yes;privacy=off
From: "ucpros" <sip:1505@iptel.org>;tag=410D9A-182
To: <sip:pashat@iptel.org>
Date: Wed, 31 Aug 2016 11:33:26 GMT
Call-ID: 90F1E4EF-6EA511E6-8015F4F4-11BF0349@192.168.1.20
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3121089664-0000065536-0000000003-0167880896
User-Agent: Cisco-SIPGateway/IOS-15.5.3.S2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1472643206
Contact: <sip:1505@192.168.1.20:5060>
Call-Info: <sip:192.168.1.20:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 68
Session-Expires: 1800
Content-Length: 0
.
.
.
Received:
SIP/2.0 604 Unknown Identity
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK2C21C6;received=80.1.1.1
From: "ucpros" <sip:1505@iptel.org>;tag=410D9A-182
To: <sip:pashat@iptel.org>;tag=5A36FA5D-57C6C0860003EE14-43C32700
Call-ID: 90F1E4EF-6EA511E6-8015F4F4-11BF0349@192.168.1.20
CSeq: 101 INVITE
Server: ser (3.3.0-pre1 (i386/linux))
Warning: 392 192.168.0.85:5060 "Noisy feedback tells: pid=1391 req_src_ip=192.168.0.86 req_src_port=5060 in_uri=sip:pashat@iptel.org:5060 out_uri=sip:pashat@iptel.org:5060 via_cnt==1"
Content-Length: 0Unknown identity, that’s a new one. I was expecting a digest challenge with a
407 Proxy Authentication Required but it wasn’t my day now was it..
It was about to be a long evening and i had to make it shorter.
I added the Alias command so that writing sip would invoke the command debug ccsip messages.
CUBE(config)#alias exec sip debug ccsip messagesAfter some brainstorming, googling and testing i was onto it. Apparently, ITSP expects to see your allocated DID range / username in the From field whenever you make a call.
My was showing the internal directory which I had to change to my allocated username.
From: "ucpros" <sip:1505@iptel.org>;tag=410D9A-182
Shows internal extension: wrong
From: "ucpros" <sip:ucpros@iptel.org>;tag=410D9A-182
Shows allocated username: right
From: "ucpros" <sip:08865423561@iptel.org>;tag=410D9A-182
Shows DID number from allocated range: rightUsually you would just have to update the External Phone Number Mask on the CUCM so it would match ITSP’s expectations, but if your case is a bit more complicated you would have to use SIP profiles to get the job done.
You can use the following set of commands to modify the From header
voice class sip-profiles 1
request INVITE sip-header From modify "(<.*:)(.*@)" "ucpros@"This command replaces anything that is before the @ with my ITSP username.
You would then have to attach it the proper outgoing dial-peer.
Dial-peer voice 1 voip
Description outgoing to ITSP
voice-class sip profiles 1
You can find very helpful documentation with real life examples of how to do it here.
You can also test your SIP profiles before you apply it with this great tool.
One-Way voice
After a rough start I was hoping for some improvement but success wasn’t giving itself up that easily. Unlike the setbacks, which continued pouring in, in buckets.
I could call now, but that was not enough.
Audio? One way, can’t hear a thing. Not a big surprise when you are behind NAT.
A quick debug ccsip messages revealed that voice packets are sent but none are received.
SIP BYE message indicated that PR=0 (Packets Received).
Received:
BYE sip:135601EA-57C6DA3C000A0C9F-43F35700@192.168.1.20:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.1.10:5060;branch=z9hG4bK2b4048cc72
From: "ucpros" <sip:100@192.168.1.10>;tag=193~caf26ba8-507b-44f8-ac22-461d3d689977-18522847
To: <sip:pashat@iptel.org>;tag=A5803C-1389
Date: Wed, 31 Aug 2016 13:23:08 GMT
Call-ID: d358b80-7c61da3c-16-a01a8c0@192.168.1.10
User-Agent: Cisco-CUCM11.0
Max-Forwards: 70
P-Asserted-Identity: "ucpros" <sip:100@192.168.1.10>
CSeq: 102 BYE
Reason: Q.850;cause=16
Session-ID: 25a321302cb9fe0e3578b2978beaa192;remote=a1fd93dd8b22cbd2ca21f6fe533ab193
P-RTP-Stat: PS=970,OS=155200,PR=0,OR=0,PL=0,JI=0,LA=0,DU=19
Content-Length: 0Red lights and yellow light bulbs were flooding my brain.
“You did configure the FW to allow SIP ALG, right?” I asked the customer.
“Sure!” he replied.
It was agreed that the customer’s FW would provide NAT support via SIP ALG (Application Layer Gateway).
The point of ALG is to check the Application layer of the packet (the SIP header in our case) and replace any IP addresses (usually LAN addresses) with it’s own address.
Something was missing, the FW wasn’t doing it’s job.
After a few sighs and clicks, the customer asked me to try again.
The second hurdle was behind me, but it was far from being the end of it.
No incoming calls
I could make outbound calls just fine but incoming calls were intermittently failing. I was baffled, I had to see what was going on the Cisco CUBE side.
Debug ccsip messages was there for the rescue once again.
My goal was to first verify that I’m getting the proper invite from ITSP.
I was. And then I wasn’t. When calls were going through I could see the proper invite reach the Cisco CUBE. When they didn’t, Cisco CUBE was desolated. There were no SIP packets coming in.
“How could it be?” I was thinking.
I had to narrow it down, find some consistencies and patterns.
I found that calls from some sources were always reaching Cisco CUBE, while others were never coming through. Who is to blame??
I had to check again. I registered my softphone (i like the free MicroSIP) to the ITSP and tried to call it. Calls were reaching it no matter what was the source.
YES!! It was my fault! A sense of hope flooded my body.
If I am to blame, surely I can fix it.
Quickly, what is the difference between Cisco CUBE and my softphone? Err.. Registration! I have to check my registration status.
CUBE#show sip-ua register statusFlat-line sound was filling my ears. I was so sure about my configuration that I missed the obvious. After all, outgoing calls and even some of the incoming ones were working well..
CUBE#show sip-ua register status
Registrar is not configuredI was missing the registrar command under SIP-UA. Outgoing calls were working because I had the authentication command in place which would pass the auth’ challenge from ITSP.
CUBE(config)sip-ua
CUBE(config-sip-ua)#credentials username ucpros password 7 0442A4334 realm iptel.org
CUBE(config-sip-ua)#registrar dns:iptel.org expires 3600CUBE#show sip-ua register status
Line peer expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
ucpros -1 23 yes normal
Registered!
The end was close, or so I thought.
CUCM: 404 Not Found
I could see the incoming INVITE messages from the ITSP but something had changed and I couldn’t quite point my finger on it. My Jabber wasn’t ringing. Now what??
Poker night was getting further away while a failed cut-off was getting closer by the minute.
I had to figure out what was wrong.
Debug ccsip messages.
Incoming INVITE. Check.
Outgoing INVITE to CUCM. Check.
200 OK from CUCM. Missing. How come?
Went through all of the CUCM incoming call flow. Flawless.
Back to Cisco CUBE. Checking out the SIP messages I’ve noticed something was wrong.
First look, nothing, looks great. The To field in the invite message to CUCM contained the right number.
Sent:
INVITE sip:UCPROS-TRUNK@192.168.1.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK12C7B7
Remote-Party-ID: <sip:pashat@192.168.1.20>;party=calling;screen=no;privacy=off
From: <sip:pashat@iptel.org>;tag=BED29A-150B
To: <sip:821101@192.168.1.10>
Date: Wed, 31 Aug 2016 18:47:10 GMT
Call-ID: 28CC4870-6EE211E6-802DCA05-6CA790D5@192.168.1.20
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0684376435-1860309478-2150091269-1822920917
User-Agent: Cisco-SIPGateway/IOS-15.5.3.S2
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1472669230
Contact: <sip:pashat@192.168.1.20:5060>
Call-Info: <sip:192.168.1.20:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 2
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270
v=0
o=CiscoSystemsSIP-GW-UserAgent 3195 4421 IN IP4 192.168.1.20
s=SIP Call
c=IN IP4 192.168.1.20
t=0 0
m=audio 8020 RTP/AVP 0 8 101
c=IN IP4 192.168.1.20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20Yet CUCM couldn’t find it.
Received:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK12C7B7
From: <sip:pashat@iptel.org>;tag=BED29A-150B
To: <sip:821101@192.168.1.10>;tag=380~caf26ba8-507b-44f8-ac22-461d3d689977-18522858
Date: Wed, 31 Aug 2016 18:47:10 GMT
Call-ID: 28CC4870-6EE211E6-802DCA05-6CA790D5@192.168.1.20
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850;cause=1
Server: Cisco-CUCM11.0
Session-ID: 00000000000000000000000000000000;remote=a1fd93dd8b22cbd2ca21f6fe533ab380
Content-Length: 0I had to take another look, something was amiss.
Right! The SIP request URI, it made no sense.
SIP-REQ-URI is the first row of the SIP header and it was showing a variation of my ITSP username while the To field had the called number. Problem is, CUCM uses the SIP-REQ-URI to route calls!
Timing couldn’t be worse but I knew what I had to do.
SIP profiles is the way to customize SIP headers in Cisco CUBE.
Not the easiest job on the planet but definitely one of the most powerful features Cisco CUBE has to offer.
My first try was to replace the SIP INVITE header.
voice class sip-profiles 2
request INVITE sip-header To copy "sip:(.*)@" u10
request INVITE sip-header SIP-Req-URI modify "UCPROS-TRUNK@(.*)" "\u10@"we would then have to associate the SIP Profile to the incoming dial peer.
voice service voip
sip
sip-profiles inbound
Dial-peer voice 2 voip
Description Incoming from ITSP
voice-class sip profiles 2 inboundBasically what I did here was to copy the called number from the To header to the SIP-REQ-URI header instead of my ITSP username.
It was working! I was exuberant. The happiest person within a hundred mile radius!
Until I wasn’t.
Test calls had strange behaviors.
They wouldn’t disconnect, reconnect or properly placed on hold. Basically any mid call feature was misbehaving in one way or another.
My patience was running on fumes now.
I was already late for the first round of bets and I really wanted the cut-off to end smoothly. No loose ends on this one.
I had to see what was happening SIP wise on the Cisco CUBE.
Debug ccsip messages revealed the problem.
Even though I changed the INVITE SIP header to reflect the proper called number to CUCM, all of the other messages that had abnormal SIP-REQ-URI were just blanks for CUCM.
It couldn’t understand BYE or any other SIP message that were coming from the ITSP.
Consequently, this one was pretty straight forward.
All i had to do was to change the INVITE to ANY on my SIP-profile to apply the changes on all of the incoming SIP messages from ITSP.
It would look something like that:
Voice class sip-profiles 2
request ANY sip-header To copy "sip:(.*)@" u10
request ANY sip-header SIP-Req-URI modify "UCPROS-TRUNK@(.*)" "\u10@"Success!! At last! What’s more, I managed to make it to the poker game before the blinds went up. Not to bad for a Tuesday night.
Epilogue
Let’s try to wrap things up here. There are few things that you would have to pay attention to when things go south on your CUBE implementation.
- First of all, debug ccsip messages is your best friend, use it. do notice that sometimes this debug won’t show you the register messages to your Registrar and you would have to use debug ccsip all. Only use the all command in a non-production router or during a maintenance window as it might crash your router.
- Check your From field in outgoing calls. If the number/user is not associated to you by the ITSP, your call will probably be rejected.
- Don’t forget to verify your registration status with show sip-ua register status.
Do not get confused by outgoing calls that are working.
Remember that you will need both the Authentication and the Credentials commands under sip-ua. - One-way or no-way audio is pretty common. It usually caused by NAT issues.
If your Cisco CUBE has only LAN interfaces, remember that someone has to replace the IP Addresses in the application layer (SIP headers), so either use SIP-Profiles or SIP-ALG on the FW. - CUCM routes calls using the SIP-REQ-URI header, not the To header.
Do verify what you receive from ITSP and change accordingly using SIP-Profiles.
In addition, there are some very good docs and tools out there, don’t be afraid to use it. - I have written a multi-part blog post on how to configure CUBE step-by-step, you can find very useful information there. Part 1 Part 2
Let me know if you have any questions or had any issues with your ITSP deployment in the comments!
Best of luck!
Build pro IOS configs. FAST.
Any reason we wouldn’t see the caller id name information passed from the cube to CUCM (we only see the number from the external number)? This is for a new deployment and carrier sent me their logs proving they are sending the information.
Hi Joey,
That’s an interesting one.
To get to the bottom of it, we would have to understand how the ITSP sends the information and see what CUBE does with it.
Can you please share the the debug ccsip messages output from CUBE for the call.
We actually only need the invite message coming from the ITSP and the Invite message going from CUBE to CUCM.
Here you go! and thank you! I don’t see any caller name information that the carrier supposedly says it’s sending us:
og Buffer (120000 bytes):
013795: May 4 19:38:17.978: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+442075500885@80.169.51.98:5060 SIP/2.0
Via: SIP/2.0/UDP 84.14.241.179:5060;branch=z9hG4bK02B375a5739bb16f051
From: ;tag=gK02303d47
To:
Call-ID: 1090680527_44656634@84.14.241.179
CSeq: 30947 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact:
Supported: timer,100rel
Session-Expires: 1800
Min-SE: 90
Content-Length: 308
Content-Disposition: session; handling=required
Content-Type: application/sdp
–More–
v=0
o=Sonus_UAC 26122 20188 IN IP4 84.14.241.179
s=SIP Media Capabilities
c=IN IP4 84.14.241.175
t=0 0
m=audio 7520 RTP/AVP 8 18 2 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
013796: May 4 19:38:17.982: //-1/0EA05A149EDA/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=+13124895108
—– ccCallInfo IE subfields —–
cisco-ani=sip:+13124895108@84.14.241.179
–More– cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=0
dest=sip:+442075500885@80.169.51.98:5060
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
013797: May 4 19:38:17.982: //-1/0EA05A149EDA/CCAPI/cc_api_call_setup_ind_common:
Interface=0x222BA730, Call Info(
Calling Number=sip:+13124895108@84.14.241.179,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=sip:+442075500885@80.169.51.98:5060(TON=Unknown, NPI=Unknown),
–More– Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=1000, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=2657
013798: May 4 19:38:17.982: //-1/0EA05A149EDA/CCAPI/ccCheckClipClir:
In: Calling Number=sip:+13124895108@84.14.241.179(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
013799: May 4 19:38:17.982: //-1/0EA05A149EDA/CCAPI/ccCheckClipClir:
Out: Calling Number=sip:+13124895108@84.14.241.179(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
013800: May 4 19:38:17.986: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
013801: May 4 19:38:17.986: :cc_get_feature_vsa malloc success
013802: May 4 19:38:17.986: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
013803: May 4 19:38:17.986: cc_get_feature_vsa count is 1
013804: May 4 19:38:17.986: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
013805: May 4 19:38:17.986: :FEATURE_VSA attributes are: feature_name:0,feature_time:1060025984,feature_id:2523
013806: May 4 19:38:17.986: //2657/0EA05A149EDA/CCAPI/cc_api_call_setup_ind_common:
–More– Set Up Event Sent;
Call Info(Calling Number=(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=(TON=Unknown, NPI=Unknown))
013807: May 4 19:38:17.986: //2657/0EA05A149EDA/CCAPI/cc_process_call_setup_ind:
Event=0x22763AD0
013808: May 4 19:38:17.986: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number +442075500885
013809: May 4 19:38:17.986: //2657/0EA05A149EDA/CCAPI/ccCallSetContext:
Context=0x3F365670
013810: May 4 19:38:17.986: //2657/0EA05A149EDA/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 2657 with tag 1000 to app “_ManagedAppProcess_Default”
013811: May 4 19:38:17.986: //2657/0EA05A149EDA/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
013812: May 4 19:38:17.986: //-1/xxxxxxxxxxxx/CCAPI/ccGetMemPoolFromContainer:
mempool not found from usrContainer(3EE42340)
013813: May 4 19:38:17.986: //-1/xxxxxxxxxxxx/CCAPI/ccCreateMemPoolInContainer:
Mempool(39F54464) created in usrContainer(3EE42340)
013814: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=2000, Params=0x3F360020, Progress Indication=NULL(0)
–More– 013815: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccCheckClipClir:
In: Calling Number=sip:+13124895108@84.14.241.179(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
013816: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccCheckClipClir:
Out: Calling Number=sip:+13124895108@84.14.241.179(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
013817: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccCallSetupRequest:
Destination Pattern=+44207550.T, Called Number=+442075500885, Digit Strip=FALSE
013818: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccCallSetupRequest:
Calling Number=sip:+13124895108@84.14.241.179(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=+442075500885(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=+13124895108, Final Destination Flag=TRUE,
Guid=0EA05A14-3038-11E7-9EDA-97A1D093B2D2, Outgoing Dial-peer=2000
013819: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/cc_api_display_ie_subfields:
ccCallSetupRequest:
cisco-username=+13124895108
—– ccCallInfo IE subfields —–
cisco-ani=sip:+13124895108@84.14.241.179
cisco-anitype=0
–More– cisco-aniplan=0
cisco-anipi=0
cisco-anisi=0
dest=+442075500885
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-rdntype=0
cisco-rdnplan=0
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
013820: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x222BA730, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=sip:+13124895108@84.14.241.179,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
Called Number=+442075500885(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
–More– Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=2000, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
013821: May 4 19:38:17.990: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
013822: May 4 19:38:17.990: :cc_get_feature_vsa malloc success
013823: May 4 19:38:17.990: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
013824: May 4 19:38:17.990: cc_get_feature_vsa count is 2
013825: May 4 19:38:17.990: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
013826: May 4 19:38:17.990: :FEATURE_VSA attributes are: feature_name:0,feature_time:1060029792,feature_id:2524
013827: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event=101, Call Id=2657
013828: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
013829: May 4 19:38:17.990: //2658/0EA05A149EDA/CCAPI/ccIFCallSetupRequestPrivate:
SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
013830: May 4 19:38:17.990: //2658/0EA05A149EDA/CCAPI/ccCallSetContext:
Context=0x3F35FFD0
–More– 013831: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=2000
013832: May 4 19:38:17.990: //2658/0EA05A149EDA/CCAPI/ccGetMediaClassTag:
media class tag 0
013833: May 4 19:38:17.990: //2658/0EA05A149EDA/CCAPI/ccSetMediaclassIp2ipTags:
media class tags set: NR 0, ASP 0
013834: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccGetMediaClassTag:
media class tag 0
013835: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccSetMediaclassIp2ipTags:
media class tags set: NR 0, ASP 0
013836: May 4 19:38:17.990: //2658/0EA05A149EDA/CCAPI/ccGet_xc_nr_asp_info:
media class tags: NR 0, ASP 0
013837: May 4 19:38:17.990: //2657/0EA05A149EDA/CCAPI/ccGet_xc_nr_asp_info:
media class tags: NR 0, ASP 0
013838: May 4 19:38:17.990: //-1/xxxxxxxxxxxx/CCAPI/cc_is_cng_fax_detect_active:
Call Id 2657
013839: May 4 19:38:17.990: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event=194, Call Id=2658
013840: May 4 19:38:17.990: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
013841: May 4 19:38:17.990: //2657/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
–More– 013842: May 4 19:38:17.990: cc_api_get_xcode_stream : 4982
013843: May 4 19:38:17.990: //2658/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
013844: May 4 19:38:17.990: cc_api_get_xcode_stream : 4982
013845: May 4 19:38:17.994: //2657/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
013846: May 4 19:38:17.994: cc_api_get_xcode_stream : 4982
013847: May 4 19:38:17.994: //2657/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
013848: May 4 19:38:17.994: cc_api_get_xcode_stream : 4982
013849: May 4 19:38:17.994: //2658/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
013850: May 4 19:38:17.994: cc_api_get_xcode_stream : 4982
013851: May 4 19:38:17.994: //2657/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
013852: May 4 19:38:17.994: cc_api_get_xcode_stream : 4982
013853: May 4 19:38:17.994: //2658/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
013854: May 4 19:38:17.994: cc_api_get_xcode_stream : 4982
013855: May 4 19:38:17.994: //2658/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
013856: May 4 19:38:17.994: cc_api_get_xcode_stream : 4982
013857: May 4 19:38:17.994: //2658/0EA05A149EDA/CCAPI/cc_api_call_proceeding:
–More– Interface=0x222BA730, Progress Indication=NULL(0)
013858: May 4 19:38:17.994: //2657/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 84.14.241.179:5060;branch=z9hG4bK02B375a5739bb16f051
From: ;tag=gK02303d47
To:
Date: Thu, 04 May 2017 19:38:17 GMT
Call-ID: 1090680527_44656634@84.14.241.179
CSeq: 30947 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Length: 0
013859: May 4 19:38:17.998: //2658/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+442075500885@10.129.177.6:5060 SIP/2.0
Via: SIP/2.0/UDP 10.129.170.3:5060;branch=z9hG4bK11DB2695
Remote-Party-ID: ;party=calling;screen=no;privacy=off
From: ;tag=573C7908-40F
To:
–More–
Date: Thu, 04 May 2017 19:38:17 GMT
Call-ID: EA2CB4D-303811E7-9EE097A1-D093B2D2@10.129.170.3
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0245389844-0808980967-2665125793-3499340498
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1493926697
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 294
v=0
o=CiscoSystemsSIP-GW-UserAgent 5218 1815 IN IP4 10.129.170.3
s=SIP Call
–More–
c=IN IP4 10.129.170.3
t=0 0
m=audio 21420 RTP/AVP 8 18 101
c=IN IP4 10.129.170.3
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
013860: May 4 19:38:17.998: //2658/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.129.170.3:5060;branch=z9hG4bK11DB2695
From: ;tag=573C7908-40F
To:
Date: Thu, 04 May 2017 19:38:18 GMT
Call-ID: EA2CB4D-303811E7-9EE097A1-D093B2D2@10.129.170.3
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
–More–
013861: May 4 19:38:18.050: //2658/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.129.170.3:5060;branch=z9hG4bK11DB2695
From: ;tag=573C7908-40F
To: ;tag=220085~075c849e-380e-4814-b788-e1624262b61d-93086961
Date: Thu, 04 May 2017 19:38:18 GMT
Call-ID: EA2CB4D-303811E7-9EE097A1-D093B2D2@10.129.170.3
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Server: Cisco-CUCM11.0
Call-Info: ;x-cisco-video-traffic-class=DESKTOP
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-ID: 695d3efa00105000a0000041d292ecd6;remote=3269c712f9763d62ef7351deab220085
P-Asserted-Identity: “Mohammad Khan”
–More–
Remote-Party-ID: “Mohammad Khan” ;party=called;screen=yes;privacy=off
Contact: ;+u.sip!devicename.ccm.cisco.com=”SEP0041D292ECD6″
Content-Length: 0
013862: May 4 19:38:18.050: //2658/0EA05A149EDA/CCAPI/cc_api_call_alert:
Interface=0x222BA730, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
013863: May 4 19:38:18.050: //2658/0EA05A149EDA/CCAPI/cc_api_call_alert:
Call Entry(Retry Count=0, Responsed=TRUE)
013864: May 4 19:38:18.050: //2657/0EA05A149EDA/CCAPI/ccCallAlert:
Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
013865: May 4 19:38:18.050: //2657/0EA05A149EDA/CCAPI/ccCallAlert:
Call Entry(Responsed=TRUE, Alert Sent=TRUE)
013866: May 4 19:38:18.050: //2657/0EA05A149EDA/CCAPI/ccCallNotify:
Data Bitmask=0x7, Call Id=2657
013867: May 4 19:38:18.054: //2657/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 84.14.241.179:5060;branch=z9hG4bK02B375a5739bb16f051
–More–
From: ;tag=gK02303d47
To: ;tag=573C7940-1C0A
Date: Thu, 04 May 2017 19:38:17 GMT
Call-ID: 1090680527_44656634@84.14.241.179
CSeq: 30947 INVITE
Require: 100rel
RSeq: 8625
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: “Mohammad Khan” ;party=called;screen=yes;privacy=off
Contact:
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Length: 0
013868: May 4 19:38:18.062: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
PRACK sip:+442075500885@80.169.51.98:5060 SIP/2.0
Via: SIP/2.0/UDP 84.14.241.179:5060;branch=z9hG4bK02B375b64dabb16f051
From: ;tag=gK02303d47
–More–
To: ;tag=573C7940-1C0A
Call-ID: 1090680527_44656634@84.14.241.179
CSeq: 30948 PRACK
Max-Forwards: 70
RAck: 8625 30947 INVITE
Content-Length: 0
013869: May 4 19:38:18.066: //2657/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 84.14.241.179:5060;branch=z9hG4bK02B375b64dabb16f051
From: ;tag=gK02303d47
To: ;tag=573C7940-1C0A
Date: Thu, 04 May 2017 19:38:18 GMT
Call-ID: 1090680527_44656634@84.14.241.179
Server: Cisco-SIPGateway/IOS-15.4.3.M3
CSeq: 30948 PRACK
Content-Length: 0
013870: May 4 19:38:36.094: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
–More– Received:
UPDATE sip:+13124895108@10.129.170.3:5060 SIP/2.0
Via: SIP/2.0/UDP 10.129.177.6:5060;branch=z9hG4bK89684926fee
From: ;tag=220085~075c849e-380e-4814-b788-e1624262b61d-93086961
To: ;tag=573C7908-40F
Date: Thu, 04 May 2017 19:38:18 GMT
Call-ID: EA2CB4D-303811E7-9EE097A1-D093B2D2@10.129.170.3
User-Agent: Cisco-CUCM11.0
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 UPDATE
Session-ID: ab0ac024bf23b78f0527ddd1ab220092;remote=3269c712f9763d62ef7351deab220085
Call-Info: ;x-cisco-video-traffic-class=MIXED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
Min-SE: 1800
P-Preferred-Identity: “UK-VOICEMAIL”
Remote-Party-ID: “UK-VOICEMAIL” ;party=calling;screen=no;privacy=off
–More–
Contact:
Content-Length: 0
013871: May 4 19:38:36.098: //2658/0EA05A149EDA/CCAPI/cc_api_call_notify:
Data Bitmask=0x7, Interface=0x222BA730, Call Id=2658
013872: May 4 19:38:36.098: //2658/0EA05A149EDA/CCAPI/cc_api_get_ccm_detected:
CallInfo(ccm detected=FALSE)
013873: May 4 19:38:36.098: //2657/0EA05A149EDA/CCAPI/ccCallNotify:
Data Bitmask=0x7, Call Id=2657
013874: May 4 19:38:36.098: //2658/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.129.177.6:5060;branch=z9hG4bK89684926fee
From: ;tag=220085~075c849e-380e-4814-b788-e1624262b61d-93086961
To: ;tag=573C7908-40F
Date: Thu, 04 May 2017 19:38:36 GMT
Call-ID: EA2CB4D-303811E7-9EE097A1-D093B2D2@10.129.170.3
Server: Cisco-SIPGateway/IOS-15.4.3.M3
CSeq: 101 UPDATE
Allow-Events: telephone-event
–More–
Contact:
Content-Length: 0
013875: May 4 19:38:36.098: //2657/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Sent:
UPDATE sip:+13124895108@84.14.241.179:5060 SIP/2.0
Via: SIP/2.0/UDP 80.169.51.98:5060;branch=z9hG4bK11DCB6B
From: ;tag=573C7940-1C0A
To: ;tag=gK02303d47
Date: Thu, 04 May 2017 19:38:18 GMT
Call-ID: 1090680527_44656634@84.14.241.179
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Max-Forwards: 70
Supported: timer,resource-priority,replaces,sdp-anat
Timestamp: 1493926716
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 UPDATE
Contact:
Min-SE: 1800
Remote-Party-ID: “UK-VOICEMAIL” ;party=called;screen=no;privacy=off
–More–
Content-Length: 0
013876: May 4 19:38:36.110: //2657/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 80.169.51.98:5060;branch=z9hG4bK11DCB6B
From: ;tag=573C7940-1C0A
To: ;tag=gK02303d47
Call-ID: 1090680527_44656634@84.14.241.179
CSeq: 101 UPDATE
Contact:
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS
Supported: timer
Session-Expires: 1800;refresher=uas
Content-Length: 0
013877: May 4 19:38:36.194: //2658/0EA05A149EDA/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
–More–
Via: SIP/2.0/UDP 10.129.170.3:5060;branch=z9hG4bK11DB2695
From: ;tag=573C7908-40F
To: ;tag=220085~075c849e-380e-4814-b788-e1624262b61d-93086961
Date: Thu, 04 May 2017 19:38:18 GMT
Call-ID: EA2CB4D-303811E7-9EE097A1-D093B2D2@10.129.170.3
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Server: Cisco-CUCM11.0
Call-Info: ;x-cisco-video-traffic-class=MIXED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uas
Require: timer
Session-ID: ab0ac024bf23b78f0527ddd1ab220092;remote=3269c712f9763d62ef7351deab220085
P-Preferred-Identity: “UK-VOICEMAIL”
Remote-Party-ID: “UK-VOICEMAIL” ;party=called;screen=no;privacy=off
–More–
Contact:
Content-Type: application/sdp
Content-Length: 246
v=0
o=CiscoSystemsCCM-SIP 220085 1 IN IP4 10.129.177.6
s=SIP Call
c=IN IP4 10.129.177.7
b=TIAS:8000
b=AS:8
t=0 0
m=audio 17672 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
013878: May 4 19:38:36.194: //2658/0EA05A149EDA/CCAPI/cc_api_caps_ind:
Destination Interface=0x0, Destination Call Id=-1, Source Call Id=2658,
Caps(Codec=0x4, Fax Rate=0x2, Fax Version:=0, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
013879: May 4 19:38:36.194: //2658/0EA05A149EDA/CCAPI/cc_api_caps_ind:
–More– Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
013880: May 4 19:38:36.194: //2657/0EA05A149EDA/CCAPI/cc_api_caps_ack:
Destination Interface=0x0, Destination Call Id=2658, Source Call Id=2657,
Caps(Codec=g729r8(0x4), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=20, Signal Type=2, Seq Num Start=6893)
013881: May 4 19:38:36.194: //2657/0EA05A149EDA/CCAPI/cc_api_caps_ack:
Destination Interface=0x0, Destination Call Id=2658, Source Call Id=2657,
Caps(Codec=g729r8(0x4), Fax Rate=FAX_RATE_VOICE(0x2), Fax Version:=0, Vad=OFF(0x1),
Modem=OFF(0x0), Codec Bytes=20, Signal Type=2, Seq Num Start=6893)
013882: May 4 19:38:36.194: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event=102, Call Id=2658
013883: May 4 19:38:36.194: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
013884: May 4 19:38:36.194: //2658/0EA05A149EDA/CCAPI/cc_api_call_connected:
Interface=0x222BA730, Data Bitmask=0x80000001, Progress Indication=NULL(0),
Connection Handle=0
013885: May 4 19:38:36.194: //2658/0EA05A149EDA/CCAPI/cc_api_call_connected:
Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
013886: May 4 19:38:36.198: //2658/xxxxxxxxxxxx/CCAPI/cc_api_ha_call_active_notify:
–More–
013887: May 4 19:38:36.198: call_info mainst_callID:0xA62, peer_callID:0xA61, confID:0x0, spi_type:4, media_flo_thru:1,num_streams:1, swmtpmsp_present:0
013888: May 4 19:38:36.198: //2658/xxxxxxxxxxxx/CCAPI/cc_api_ha_call_active_notify:
013889: May 4 19:38:36.198: stream[0]: callid:0xA62, media_passthrough:1
013890: May 4 19:38:36.198: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event=110, Call Id=2658
013891: May 4 19:38:36.198: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
013892: May 4 19:38:36.198: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event=206, Call Id=2658
013893: May 4 19:38:36.198: //2658/0EA05A149EDA/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
013894: May 4 19:38:36.198: //2658/0EA05A149EDA/SIP/Call/sipSPICallInfo:
The Call Setup Information is:
Hi Joey,
Seems like to you got it right. The ITSP doesn’t send name information for the call.
You can show him the invite message that you receive.
Just wondering how did you register your softphone (the free MicroSIP) to the ITSP ?
Hi Pasha,
Just wondering how did you register your softphone (the free MicroSIP) to the ITSP ?
Hi Jason,
The concept is quite similar to configuring the CUBE.
The ITSP should provide you with your DID number, username and password.
These are the only authentication parameters, it doesn’t matter if you try to register with a SBC or a SIP client.
Just enter the parameters in the right place and you are good to go. The Domain field is usually the FQDN/IP of your ITSP servers (similar to realm in CUBE).
Does that answer your question or is there a specific issue that you are facing?
Hello,
ME again :). From time to time our users have issues dialing a certain number at times (not all the time). For example today: User makes an out going call and we get back CCM_SIP_503_SERVICE_UNAVAILABLE from our COLT provider. But i couldn’t get a trace because the user didn’t notify me on time and didn’t want to retry the number. Is there any other ways troubleshoot? I have a ticket opened with our provider but this happens at least once a week with COLT.
Call flow below:
PHONE>CUCM>CUBE>ITSP-SBC
ITSP>CUBE>CUCM>PHONE
CUCM version 11.5.1.12900
37050976.002 |15:09:04.591 |AppInfo |SIPTcp – wait_SdlReadRsp: Incoming SIP TCP message from 10.129.170.3 on port 5060 index 101447 with 467 bytes:
[6979829,NET]
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 10.129.177.6:5060;branch=z9hG4bK32ee56b607e29
From: “USER” ;tag=2332481~075c849e-380e-4814-b788-e1624262b61d-97134013
To: ;tag=F8AFEFAC-26FD
Date: Tue, 12 Sep 2017 14:09:04 GMT
Call-ID: eda58580-9b71ea80-28333-6b1810a@10.129.177.6
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.4.3.M3
Content-Length: 0
Hi Joey,
How are you doing?
By your description, I presume that the fault is not with the number as “this happens at least once a week”, and i guess it happens with different numbers.
While troubleshooting, i don’t like to be presumptions so i check everything, especially in ambiguous faults like this.
So just make a call to the same number see if it’s working.
If it doesn’t it might be the number, if it does work, it would point the finger to your ITSP.
That being said..
It seems like the issue is with your ITSP, 503 Service Unavailable is a server error (all 5xx errors are).
This specific error means that the server can’t process SIP requests properly at this time.
And this is bad..
I would do the following:
1. Check how is the ITSP configured in CUBE. is it by name? IP address? Does it have a backup server? In most cases there should be, as it’s probable that COLT is working with more than one server.
So check you redundancy mechanism as 503 response should get the CUBE to try the next routing option.
2. Set up proper debug (debug ccsip messages) and logging for SIP messages on CUBE. just make a quick search on google on how to set up logging for your environment.
It would usually include not logging to console, enlarging the logging buffer and depending on the load on the router, sending the logs to external server.
After that is done, i would check daily in the log files for 503 messages and look for common ground by observing CUBE’s routing decisions, ITSP responses and general call flow for the conversation.
3. Open a case with you ITSP, which you already did 🙂
Let me know how it went.
I have the same problem to specific number that i dialing
Have your itsp route the number over a different path. That’s what I suggested to our itsp and it resolved our issue.