How to configure Cisco CUBE with ITSP, and get to poker night on time.

That did not go as planned. Doubt started to cripple down my spine.Cisco Cube config
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

 

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 messages

The 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: 0

Unknown 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 messages

After 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: right

Usually 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: 0

Red 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 status

Flat-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 configured

I 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 3600
CUBE#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:20

Yet 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: 0

I 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 inbound

Basically 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.

11 thoughts on “How to configure Cisco CUBE with ITSP, and get to poker night on time.”

  1. 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.

    1. 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.

      1. 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:

        1. 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.

  2. Just wondering how did you register your softphone (the free MicroSIP) to the ITSP ?

  3. Hi Pasha,

    Just wondering how did you register your softphone (the free MicroSIP) to the ITSP ?

    1. 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?

  4. 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

    1. 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.

        1. Have your itsp route the number over a different path. That’s what I suggested to our itsp and it resolved our issue.

Leave a Reply

Your email address will not be published. Required fields are marked *