It’s Monday morning, you are checking your Email after a long weekend just to find out that your boss was quite busy and you have been assigned a new project.
The good news? It involves ITSP and CUBE.
Edit: I recommended using the CUBE Config Utility in conjunction with this post
Contents
I figure that you’ve already heard that PRIs are not the latest fashion so I’ll skip the long introduction. I even suspect that some of you have already implemented SIP Trunking to Service Providers.
For those who didn’t, ITSP (Internet Telephony Service Provider) is the Service Provider for SIP services that are slowly but surely replacing the good old PRIs.
CUBE is the device that will securely connect our company’s VOIP network to the ITSP over the internet.
And this is how CUBE configuration is done:
Step 1: ITSP. Know your enemy.
In order for you to nail it right the first time (without banging your head against the wall), before you start with any CUBE configuration, you should get your facts straight. Get in touch with the ITSP and ask them for the following information:
- SIP Trunk IP Address – IP Address of the ITSP’s proxy(s)
- SIP Trunk FQDN – the FQDN of the proxy(s)
- SIP trunk port number – 5060 by default
- Transport layer – TCP/UDP
- Supported codec(s)
- Fax protocol support – T.38 / Pass Through (g711)
- DTMF signaling Method
- Early offer requirements
- Registration requirements – username, password, realm
- Digest authentication requirements – username, password, realm
- Calling Number – number of digits to send in the from field
Step 2: Architect CUBE. Prepare yourself.
If the pre-sale didn’t do the design fully, now is the time to realize the connectivity subtleties.
CUBE’s job, among others, is to act as a demarcation point between the enterprise network and the internet. That being said, CUBE is not a security device per se, rather it’s strength lies in implementing it according to best practice.
You can look at it as a proxy to all VOIP traffic between the internal and the external network. The internal network sees one side and the external the other, allowing the internal network to be completely hidden from the external one.
Now, for that to happen several rules should be preserved.
First of all, place your CUBE in a DMZ. It’s bad practice to place it facing the internet with no FW in the front.
Second, enable NAT on the FW to translate external IP address to CUBE’s address.
Third, SIP ALG (Application Layer Gateway) feature on the FW, should inspect voice packets and in turn, replace the IP address fields in the SIP headers, from CUBE’s address to the external address.
*You can actually skip the last two steps if you implemented two interfaces on the CUBE (given CUBE’s WAN interface has a legal routable IP address).
Step 3: CUCM. Stay on the beaten track.
Nothing new here. Just configure a trunk that points to CUBE’s address or hostname.
If you are looking for a High Availability solution you should take a look here and here for best practice.
Follow up with your regular Route Patterns and Route Lists.
Step 4: CUBE Configuration. Start globally.
Finally, it’s time to get our CUBE configuration going. First thing to do would be to enable CUBE application and URI based routing.
Voice service voip mode border-element license capacity X allow connection SIP to SIP SIP call-route url
It would also be a good time to configure some DNS servers in order to be able to resolve names when necessary.
ip name-server 8.8.8.8 4.4.4.4
Step 5: CUBE Configuration. Build the foundations.
And the foundations are, as you might have guessed, our dial-peer structure.
So how do we build it?
Personally, I love them nice and organized, each one having its own purpose. Makes it very easy to troubleshoot afterward.
The first thing to do would be to set up the structure.
Dial-peer structure
I use the following structure in all of my deployments and it works great.
- Incoming DP from ITSP
- Incoming DP from CUCM
- Outgoing DP to CUCM
- Outgoing DP to ITSP
This is the point where you want to get a cup of coffee as the next section of CUBE configuration will involve your favorite subject:
Dial-Peer matching
Actually, this demon can be conquered quite easily as long as you know what goes first.
So, without further ado, this is how the magic happens:
SIP: Inbound dial-peer matching preference:
- voice class uri URI-class-identifier with incoming uri {via} URI-class-identifier
- voice class uri URI-class-identifier with incoming uri {request} URI-class-identifier
- voice class uri URI-class-identifier with incoming uri {to} URI-class-identifier
- voice class uri URI-class-identifier with incoming uri {from} URI-class-identifier
- incoming called-number DNIS-string
- answer-address ANI-string
SIP: outbound dial-peer matching preference:
- destination route-string
- destination URI-class-identifier with target carrier-id string
- destination-pattern with target carrier-id string
- destination URI-class-identifier
- destination-pattern
- target carrier-id string
As you can see, SIP and URI based parameters have priority over dialed numbers so it’s better to get familiar with it.
Now, that the force is strong with you, let’s see some examples. I’ll use the following parameters:
- DID is 97212345XX
- Outbound calls are prefixed with a 9
- ITSP Server: ucrpos.net
- CUCM pub: 192.168.1.10
- CUCM sub: 192.168.1.11
Incoming DP from ITSP
Easiest way to get all of the traffic coming from ITSP is to match your DID range
dial-peer voice 1 voip description incoming calls from ITSP session protocol sipv2 incoming called-number 97212345.. voice-class codec 1 dtmf-relay rtp-nte sip-notify no vad
Incoming DP from CUCM
voice class uri 2 SIP host ipv4:192.168.1.10 host ipv4:192.168.1.11 dial-peer voice 2 voip description incoming calls from CUCM session protocol sipv2 incoming uri via 2 voice-class codec 1 dtmf-relay rtp-nte sip-notify no vad
Using incoming uri via is a great way to match calls coming from CUCM servers. First, CUCM will always replace the VIA field with its own address (or host). Second, it has the highest priority in dial-peer matching
That is how the incoming packet from CUCM would look:
Received:
INVITE sip:403454@192.168.1.20:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.10:5060;branch=z9hG4bK1279e20870
From: "ucpros" <sip:100@192.168.1.10>;tag=63~caf26ba8-507b-44f8-ac22-461d3d689977-32037284
To: <sip:403454@192.168.1.20>Outgoing DP to CUCM
Nothing fancy here, it’s a good practice to keep the DID structure here with the destination-pattern command:
dial-peer voice 11 voip description Outgoing calls to CUCM destination-pattern 97212345.. session protocol sipv2 session target ipv4:192.168.1.10 voice-class codec 1 dtmf-relay rtp-nte sip-notify no vad
Outgoing DP to ITSP
Create as many DP as you need for your dial plan. It should look something like this:
dial-peer voice 10 voip description Outgoing calls to ITSP destination-pattern [2-9]…….. session protocol sipv2 session target dns:ucpros.net voice-class codec 1 dtmf-relay rtp-nte sip-notify no vad
Step 6: CUBE Authentication and Registration
Authentication and registration are two methods that have different roles in the SIP-based SP architecture.
In most cases, what you’ll see is that for outgoing calls, the ITSP will challenge you with digest authentication. It will look something like this:
Received:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK2B595B;received=84.84.5.5
From: "ucpros" <sip:100@localhost>;tag=1B41168-16C2
To: <sip:pashat@iptel.org>;tag=3B6A681F-57FE7956000BB3F6-C4437700
Call-ID: ED38729-8FDC11E6-8009C435-E1F05117@192.168.1.20
CSeq: 101 INVITE
Proxy-Authenticate: Digest realm="https://ucpros.net/", nonce="V/57q1f+eVNRh1YSGWtBICw3xqS+b2gG"
Server: ser (3.3.0-pre1 (i386/linux))
Warning: 392 192.168.0.85:5060 "Noisy feedback tells: pid=1820 req_src_ip=192.168.0.155 req_src_port=5060 in_uri=sip:pashat@iptel.org out_uri=sip:pashat@iptel.org via_cnt==1"
Content-Length: 0In order for your CUBE to pass the auth challenge you’d have to configure the following parameters:
SIP-ua authentication username ucpros password 7 123a1231245ade realm ucpros.net
For the ITSP to know where to send your calls, there is a need for registration. Of course they would have to provide you all the details beforehand.
Registration is done with the following config:
sip-ua credentials username ucpros password 7 1243124ea3432 realm ucpros.net registrar dns:ucpros.net
To check if you are registered, run the following command
CUBE#show sip-ua register status
Line peer expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
ucpros -1 56 yes normal
CUBE#Now, if you have issues with registration, a simple debug ccsip messages won’t do it. This is because by default, outgoing, non-call related debugs just won’t appear there. If you want to debug your registration run the Debug ccsip non-call command along with debug ccsip messages to get the full output.
This sums up the basics of CUBE configuration. There is one more thing though that you have to do to be able to receive calls. For your CUBE to accept SIP messages from a certain host, you have to let your CUBE know about it implicitly. I’ve covered the process in the next post in the series. If you want to disable this feature (not recommended) and accept the security risks, just place the command no ip address trusted authenticate under voice service voip configuration.
If you have any issues, questions, doubts or feel that something is missing, please feel free to post it in the comments below.
Build pro IOS configs. FAST.
excelent post!
Thanks. Happy to help.
Why would t you add a preference on the dial peer? :-). Btw do you ever set a loopback for the connection to the itsp?
Hi Jc,
The “preference” command exists on the dial-peer whether you manually enter it or not. The preference value is set by default to “0”, which means the highest priority.
So “preference” is only needed if you want to prioritize a certain dial-peer over the other.
Regarding the loopback, i presume that you mean binding the loopback address for signaling and media to use in SIP messages towards the ITSP.
There are no restrictions on which interface to bind your VOIP communication to, the rule of thumb is to use the closest routable interface to the destination. For example, if your next hop towards the ITSP would be the FW, it would be logical to bind VOIP traffic to an interface that routes towards the FW. On CUCM facing dial-peers it’s best to set the binding to an interface that routes to CUCM. That being said, there are dozens of different scenarios and topologies, each requires a slightly different solution. Do you have a specific scenario in mind?
Nope, you answered my question for me! Man, I can’t say how much I appreciate this blog! I have been going over sip trunk and cube guide… and I must admit I messed a few things out while I was setting up my cube configuration and going back to change a few things on the cucm side, so thank you and keep it up!!!!!
Hi,
Thanks ,your explanation cleared up a lot of things. But I have one question , please help me out as im new to this. We have taken a new ITSP service, they are asking for the below value to be changed to connect to their service.
this
Contact:
need to be changed to this
can you please provide the command, im in urgent need of this.
Thank you
I have cleared that hurdle, but my register message needs to be changed too.
from
REGISTER sip:proxy.trunk.seven13.tnltd.net:5060 SIP/2.0
to
REGISTER sip:856782xxxx SIP/2.0
Can you please provide the command for that.
Thank you
Hi
Was able to fix that, still its not registering, debug below
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.100.45:5060;received=13.13.13.13;branch=z9hG4bK1A0722C2;rport=56416
From: ;tag=9EFD6C50-B17
To: ;tag=1591349535-1493025884924
Call-ID: B2C32019-27A011E7-86F5B472-62A085D2
Timestamp: 1493026948
CSeq: 251 REGISTER
WWW-Authenticate: DIGEST qop=”auth”,nonce=”BroadWorksXj1vx29rwTrm53mpBW”,realm=”BroadWorks”,algorithm=MD5
Content-Length: 0
043198: *Apr 24 09:42:28.180: //170181/0
SIPTEST#00000000000/SIP/Info/sipSPICheckResponseExt: non-INVITE response with no RSEQ – do not disable IS_REL1XX
043199: *Apr 24 09:42:28.180: //170181/000000000000/SIP/Error/sipSPIHandleAuthChallenge: Error getting credentials
Can you please help out
Thanks
Hi Sharaq,
seems like your register message is missing the proper credentials.
Please attach the register message you send to ITSP and your sip-ua config.
I would also recommend you to download the CUBE Configuration Utility from this website, it would help you to get your configuration straight.
Hi
Please note our current ITSP provides a physical ITSP line to the cube, we are taking another ITSP who is cloud-based and i need to set it up.
Sent:
REGISTER sip:856782xxxx SIP/2.0
Via: SIP/2.0/UDP 192.168.100.45:5060;branch=z9hG4bK1A05D4AF
From: ;tag=9EE4ADEC-1E2D
To:
Date: Mon, 24 Apr 2017 09:15:26 GMT
Call-ID: B2C32019-27A011E7-86F5B472-62A085D2
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1493025326
CSeq: 242 REGISTER
Contact:
Expires: 3600
Supported: path
Authorization: Digest username=”856782xxxx”,realm=”proxy.trunk.seven13.tnltd.net”,uri=”sip:proxy.trunk.seven13.tnltd.net:5060″,response=””,nonce=””
Content-Length: 0
sip-ua
credentials username 856782xxxx password 7 xxxx realm proxy.trunk.seven13.tnltd.net
authentication username 856782xxxx password 7 xxxx realm proxy.trunk.seven13.tnltd.net
retry invite 4
retry response 3
retry bye 2
retry cancel 2
retry notify 6
retry register 5
timers notify 1000
timers register 1000
registrar 1 ipv4:10.10.10.2 expires 3600
registrar 2 dns:proxy.trunk.seven13.tnltd.net expires 60 auth-realm proxy.trunk.seven13.tnltd.net
Thank you
Seems like we have a realm miss-match.
Try removing the realm option or change it to BroadWorks.
Hi , thanks a lot!!!
changing the realm to broadworks worked, out going is working fine .
Just 2 questions 🙂
1. Incoming not working, this is the debug when i call in,
SIPTEST#
007996: *Apr 24 17:32:48.434: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:856782xxxx@192.168.100.45:5060 SIP/2.0
Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKf8vq8n205gr0ambed361.1
From: “Unavailable”;tag=355001702-1493054027756-
To: “856782xxxx 856782xxxx”
Call-ID: BW101347756240417-577832090@216.27.193.70
CSeq: 276446199 INVITE
Contact:
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Call-Info: ;appearance-index=1
Recv-Info: x-broadworks-client-session-info
Accept: application/media_control+xml,application/sdp,multipart/mixed
Supported:
Max-Forwards: 39
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 291
v=0
o=BroadWorks 846750027 1 IN IP4 216.27.201.249
s=-
c=IN IP4 216.27.201.249
t=0 0
m=audio 22022 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
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=sendrecv
a=maxptime:20
007997: *Apr 24 17:32:48.446: //2881/DE89A7F89DAB/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKf8vq8n205gr0ambed361.1
From: “Unavailable”;tag=355001702-1493054027756-
To: “856782xxxx 856782xxxx”
Date: Mon, 24 Apr 2017 17:32:48 GMT
Call-ID: BW101347756240417-577832090@216.27.193.70
CSeq: 276446199 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
007998: *Apr 24 17:32:48.450: //2881/DE89A7F89DAB/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKf8vq8n205gr0ambed361.1
From: “Unavailable”;tag=355001702-1493054027756-
To: “856782xxxx 856782xxxx”;tag=161C128-1E8
Date: Mon, 24 Apr 2017 17:32:48 GMT
Call-ID: BW101347756240417-577832090@216.27.193.70
CSeq: 276446199 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=21
Content-Length: 0
007999: *Apr 24 17:32:48.486: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIPTEST#ACK sip:856782xxxx@192.168.100.45:5060 SIP/2.0
Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKf8vq8n205gr0ambed361.1
CSeq: 276446199 ACK
From: “Unavailable”;tag=355001702-1493054027756-
To: “856782xxxx 856782xxxx”;tag=161C128-1E8
Call-ID: BW101347756240417-577832090@216.27.193.70
Max-Forwards: 39
Content-Length: 0
2. My ITSP guy is sayin, “I do not see your registered at this time. When I send you the 401 unauthorized, you need to send a new REGISTER message with authentication.
The flow is as such, you send register message without authentication, I reply with a 401, you send a register message with authentication and receive a 200 OK.”
Should i be concerned?
For the first part, it seems like CUBE sends the forbidden message. make sure that your ITSP ip addresses are configured in the ip address trust list (you can see an extended explanation in the second part 2 of this article series.
For the second part, you can check your registration with the “show sip-ua register status” command. look for the “Reg” status.
In most cases, registration is actually just for incoming calls. That is how the ITSP knows where to send calls for your DID block. Registration uses the “credentials” command under sip-ua first, so make sure your realm is good there.
For outgoing calls your ITSP is right. you send an invite, get a challenged response and send another invite with credentials. this is where the authentication command under sip-ua kicks in.
I think this post http://localhost/ucconfigure-cisco-cube/ might be of help in your case.
The sip line is register status shows as yes, outgoing calls are working fine, incoming are also coming to the cube, here is a debug for incoming call,
after quite a few invite and try messages this message shows up,
016097: *Apr 24 19:51:38.397: //4212/40024979AC57/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/UDP 216.27.201.249:5060;branch=z9hG4bKu8ah1u10agd13mjlr160.1
From: “john ed “;tag=1495946870-1493062351914-
To: “856782xxxx 856782xxxx”;tag=1E0DC04-D6F
Date: Mon, 24 Apr 2017 19:51:38 GMT
Call-ID: BW1232319142404171403269964@216.27.193.70
CSeq: 280608278 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=16
Content-Length: 0
Great to hear that things are moving forward.
Cause 16 is Normal Call Clearing.
The view is quite limited from here but it looks like a call routing issue.
You should verify that you have proper dial-peers that point towards CUCM.
You can verify it with SIP debug. Make sure that CUBE sends an invite towards CUCM in the process and check for the response. If CUCM is not involved, CUBE probably can’t find a match for the outgoing leg or sends it to the wrong destination.
I had added the trust list, but still the incoming call is failing.
Hi , its finally working with incoming too. Thanks a lot for your help.
Dial-peer was misconfigured 🙂
I’m having the same issue with incoming calls. Outgoing are working fine. Can you post examples of your dial-peers? that would be very helpful.
Thanks for your ports
Hi Fernando,
Can you please post the output of debug ccsip messages while the issue occurs?
Nice one! I am planning a SIP implementation and this post will help a lot!
We have a CUBE implementation with the SIP-UA configurations but I could not find any SIP or proxy servers mentioned. Only under the dial-peers I see the session target of the ISP server mentioned.
So am just trying to understand how this setup works and is it not mandatory to mention the register server address in SIP-UA.
Please clarify my doubts.
Hi Rad,
Sorry for the late response,
Usually ITSPs require registration to allow incoming calls
as it will allow them to send traffic to co-relate your DID range with your IP address, just like CUCM does with phones (registers an ext with it’s location in the network – it’s IP address).
If they don’t use registration, they would have to manually add every entry to their routing table. Imagine you would have to add every phone to CUCM with it’s IP address.. not only it makes provisioning hellish it’s also quite difficult to maintain as IP addresses tend to change.
Referring you question, i can’t see your configuration but you can check you registration status by running
“show sip-ua register status”
If it is indeed not registered, my guess would be that your ITSP uses static routing (much like we do with dial-peers). Although not likely, it is still possible..
very awesome post..keepup the good work.
Thanks Nitin,
really appreciate the feedback.
Excellent Post
Thank you!
I hope you find it helpful 🙂
Hello i want to ask something
i do the same configuration on my SIP Router but without the Command
mode border-element
and the call work fine
can you correct me if im wrong
Hi,
The Mode Boarder-Element command enables some CUBE related CLI commands.
It even requires a router reset on some platforms.
The command is not required for basic functionality tho, this is taken care of by the ‘allow connections sip-to-sip’.
Hope that helps.
Pasha.
Yes it help
Thanks so much pasha
Very good explanation..!!
Thanks for taking the time to comment!
Great post Pasha Teplitsky, definitely very intuitive.
Thank you for the feedback. Much appreciated!
Hello Team,
I need your help:
I have a problem with the username that expect my ITSP:
with my cube I cant register my account, but when I register with phoneline (softphone) it work properly.
my ITSP expect the username in this format:
555111@net.com — example
Hi Guillermo,
why won’t you open a thread in the forum section and we’ll get to the bottom if it?
Hey UCPROS,
Thanks for this BLOG you guys are maintaining. I have reached here via cisco forums website when I was searching to setup SIP trunk between ITSP – CUBE with authentication.
I have been used to with un-authenticated SIP trunks. This is something new i got to know.
Cheers and appreciate to your efforts in managing. (+5)
Very instructive.
Keep up the good work.
Hello,
I am unable to make calls and getting beep sound.Please find the below logs.Can you please help us.
000269: *Aug 22 15:50:21.211: //170/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIPTEST#OPTIONS sip:216.27.198.134:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.45:5060;branch=z9hG4bKEA1265
From: ;tag=129B50-119B
To:
Date: Sat, 22 Aug 2020 15:50:21 GMT
Call-ID: 4D1F1F7-E3C611EA-80B1E635-5D222D82@192.168.100.45
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
CSeq: 101 OPTIONS
Contact:
Content-Length: 0
SIPTEST#
000270: *Aug 22 15:50:42.019: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:8558504678@192.168.100.45:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.100.25:5060;branch=z9hG4bK1dcb3a3df93b
From: ;tag=ea258a71-6a69-41e8-b120-c7018824bf14-27815602
To:
Date: Sat, 22 Aug 2020 04:59:26 GMT
Call-ID: 3f4b5080-f401a62e-a08-1964a8c0@192.168.100.25
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Contact:
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Cisco-Guid: 1061900416-0000065536-0000002568-0426027200
Session-Expires: 1800
P-Asserted-Identity:
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 216
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 192.168.100.25
s=SIP Call
c=IN IP4 192.168.100.25
t=0 0
m=audio 24962 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
000271: *Aug 22 15:50:42.023: //-1/3F4B50800000/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=2122
—– ccCallInfo IE subfields —–
cisco-ani=2122
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=8558504678
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
000272: *Aug 22 15:50:42.027: //-1/3F4B50800000/CCAPI/cc_api_call_setup_ind_common:
Interface=0x4A299774, Call Info(
Calling Number=2122,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8558504678(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=17, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=171
000273: *Aug 22 15:50:42.027: //-1/3F4B50800000/CCAPI/ccCheckClipClir:
In: Calling Number=2122(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
000274: *Aug 22 15:50:42.027: //-1/3F4B50800000/CCAPI/ccCheckClipClir:
Out: Calling Number=2122(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
000275: *Aug 22 15:50:42.027: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
000276: *Aug 22 15:50:42.027: :cc_get_feature_vsa malloc success
000277: *Aug 22 15:50:42.027: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
000278: *Aug 22 15:50:42.027: cc_get_feature_vsa count is 1
000279: *Aug 22 15:50:42.027: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
000280: *Aug 22 15:50:42.027: :FEATURE_VSA attributes are: feature_name:0,feature_time:1301729136,feature_id:17
000281: *Aug 22 15:50:42.027: //171/3F4B50800000/CCAPI/cc_api_call_setup_ind_common:
Set Up Event Sent;
Call Info(Calling Number=2122(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8558504678(TON=Unknown, NPI=Unknown))
000282: *Aug 22 15:50:42.027: //171/3F4B50800000/CCAPI/cc_process_call_setup_ind:
Event=0x4D067D98
000283: *Aug 22 15:50:42.031: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 8558504678
000284: *Aug 22 15:50:42.031: //171/3F4B50800000/CCAPI/ccCallSetContext:
Context=0x4D994050
000285: *Aug 22 15:50:42.031: //171/3F4B50800000/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 171 with tag 17 to app “_ManagedAppProcess_Default”
000286: *Aug 22 15:50:42.035: //171/3F4B50800000/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
000287: *Aug 22 15:50:42.039: //171/3F4B50800000/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=15, Params=0x4D995560, Progress Indication=NULL(0)
000288: *Aug 22 15:50:42.039: //171/3F4B50800000/CCAPI/ccCheckClipClir:
In: Calling Number=7326402122(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
000289: *Aug 22 15:50:42.039: //171/3F4B50800000/CCAPI/ccCheckClipClir:
Out: Calling Number=7326402122(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed)
000290: *Aug 22 15:50:42.039: //171/3F4B50800000/CCAPI/ccCallSetupRequest:
Destination Pattern=[2-9]..[2-9]……$, Called Number=8558504678, Digit Strip=FALSE
000291: *Aug 22 15:50:42.039: //171/3F4B50800000/CCAPI/ccCallSetupRequest:
Calling Number=7326402122(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8558504678(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=2122, Final Destination Flag=TRUE,
Guid=3F4B5080-0001-0000-0000-0A081964A8C0, Outgoing Dial-peer=15
000292: *Aug 22 15:50:42.039: //171/3F4B50800000/CCAPI/cc_api_display_ie_subfields:
ccCallSetupRequest:
cisco-username=2122
—– ccCallInfo IE subfields —–
cisco-ani=7326402122
cisco-anitype=0
cisco-aniplan=0
cisco-anipi=0
cisco-anisi=1
dest=8558504678
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
000293: *Aug 22 15:50:42.039: //171/3F4B50800000/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x4A299774, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=7326402122,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User, Passed, Presentation=Allowed),
Called Number=8558504678(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=15, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
000294: *Aug 22 15:50:42.039: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
000295: *Aug 22 15:50:42.039: :cc_get_feature_vsa malloc success
000296: *Aug 22 15:50:42.039: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
000297: *Aug 22 15:50:42.039: cc_get_feature_vsa count is 2
000298: *Aug 22 15:50:42.039: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
000299: *Aug 22 15:50:42.039: :FEATURE_VSA attributes are: feature_name:0,feature_time:1301728912,feature_id:18
000300: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/ccIFCallSetupRequestPrivate:
SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
000301: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/ccCallSetContext:
Context=0x4D995510
000302: *Aug 22 15:50:42.043: //171/3F4B50800000/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=15
000303: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/cc_api_call_disconnected:
Cause Value=188, Interface=0x4A299774, Call Id=172
000304: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=188, Retry Count=0)
000305: *Aug 22 15:50:42.043: //171/3F4B50800000/CCAPI/ccCallReleaseResources:
release reserved xcoding resource.
000306: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/ccCallSetAAA_Accounting:
Accounting=0, Call Id=172
000307: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/ccCallDisconnect:
Cause Value=188, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=188)
000308: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/ccCallDisconnect:
Cause Value=188, Call Entry(Responsed=TRUE, Cause Value=188)
000309: *Aug 22 15:50:42.043: //172/3F4B50800000/CCAPI/cc_api_call_disconnect_done:
Disposition=-11, Interface=0x4A299774, Tag=0x0, Call Id=172,
Call Entry(Disconnect Cause=188, Voice Class Cause Code=0, Retry Count=0)
000310: *Aug 22 15:50:42.047: //172/3F4B50800000/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
000311: *Aug 22 15:50:42.047: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
000312: *Aug 22 15:50:42.047: :cc_free_feature_vsa freeing 4D96CE88
000313: *Aug 22 15:50:42.047: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
000314: *Aug 22 15:50:42.047: vsacount in free is 1
000315: *Aug 22 15:50:42.047: //171/3F4B50800000/CCAPI/ccCallDisconnect:
Cause Value=188, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
000316: *Aug 22 15:50:42.047: //171/3F4B50800000/CCAPI/ccCallDisconnect:
Cause Value=188, Call Entry(Responsed=TRUE, Cause Value=188)
000317: *Aug 22 15:50:42.051: //171/3F4B50800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.100.25:5060;branch=z9hG4bK1dcb3a3df93b
From: ;tag=ea258a71-6a69-41e8-b120-c7018824bf14-27815602
To:
Date: Sat, 22 Aug 2020 15:50:42 GMT
Call-ID: 3f4b5080-f401a62e-a08-1964a8c0@192.168.100.25
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
000318: *Aug 22 15:50:42.051: //171/3F4B50800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 192.168.100.25:5060;branch=z9hG4bK1dcb3a3df93b
From: ;tag=ea258a71-6a69-41e8-b120-c7018824bf14-27815602
To: ;tag=12ECB4-18A5
Date: Sat, 22 Aug 2020 15:50:42 GMT
Call-ID: 3f4b5080-f401a62e-a08-1964a8c0@192.168.100.25
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Reason: Q.850;cause=0
Content-Length: 0
000319: *Aug 22 15:50:42.051: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:8558504678@192.168.100.45:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.100.25:5060;branch=z9hG4bK1dcb3a3df93b
From: ;tag=ea258a71-6a69-41e8-b120-c7018824bf14-27815602
To: ;tag=12ECB4-18A5
Date: Sat, 22 Aug 2020 04:59:26 GMT
Call-ID: 3f4b5080-f401a62e-a08-1964a8c0@192.168.100.25
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: presence
Content-Length: 0
000320: *Aug 22 15:50:42.055: //171/3F4B50800000/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x4A299774, Tag=0x0, Call Id=171,
SIPTEST#Call Entry(Disconnect Cause=188, Voice Class Cause Code=0, Retry Count=0)
000321: *Aug 22 15:50:42.055: //171/3F4B50800000/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
000322: *Aug 22 15:50:42.055: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
000323: *Aug 22 15:50:42.055: :cc_free_feature_vsa freeing 4D96CF68
000324: *Aug 22 15:50:42.055: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
000325: *Aug 22 15:50:42.055: vsacount in free is 0
SIPTEST#