Archive for the ‘Dial-Peers’ Category

One of our customer has multiple sites across the globe including sites in UK and US.

Their initial design was to send all UK calls from US over a SIP trunk to break out from a UK gateway for LCR (least cost routing). For some reason they stopped using that trunk and configured local dial peers on US gateways for international calls. All sites were working fine as they were going through one route pattern (for international calls), one route list (Local Route Group) except one site. This site was getting an ‘unallocated/unassigned number’ when calling an international number (UK inour case). This was a bit suprising as all sites were using same settings on Route Pattern, Route List , Route Group etc.

I thought to first find out if our dialled number is hitting the gateway as it is without any change. Did a CCAPI INOUT to find out as follows: (The X mark in Calling/Called number can be any digit)
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_supported_data: data_mode=0×10082
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructTDUsrContainer: usrContainer[0x6408896C], magic[FACE0FFF]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x6408896C, tagID=6, dataSize=16, instID=-1,modifier=2
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x65C89E68], nxtElem[0x0], magic[0xFACE0FFF] tagID[6], dataLen[16], modif[2]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x65C89E68] instID[-1] into container[0x6408896C]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x6408896C, tagID=22, dataSize=12, instID=-1,modifier=4
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x638DCC78], nxtElem[0x0], magic[0xFACE0FFF] tagID[22], dataLen[12], modif[4]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x638DCC78] instID[-1] into container[0x6408896C]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:

02:05:19: cc_api_call_setup_ind:

02:05:19:  cisco-username=Sharon Sidd
02:05:19: —– ccCallInfo IE subfields —–

02:05:19:  cisco-ani=585XXX50X0
02:05:19:  cisco-anitype=1
02:05:19:  cisco-aniplan=1
02:05:19:  cisco-anipi=0
02:05:19:  cisco-anisi=1

02:05:19:  dest=90114411898X1XXX    <<<< As you can see Call manager handed over the same number which was dialled

02:05:19:  cisco-desttype=0
02:05:19:  cisco-destplan=0
02:05:19:  cisco-rdn=

02:05:19:  cisco-rdntype=-1
02:05:19:  cisco-rdnplan=-1
02:05:19:  cisco-rdnpi=-1
02:05:19:  cisco-rdnsi=-1
02:05:19:  cisco-redirectreason=-1

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: (vdbPtr=0x6428E260, callInfo={called=90114411898X1XXX,called_oct3=0×80,calling=585XXX50X0,calling_oct3=0×11,calling_oct3a=0×81,

calling_xlated=false,subscriber_type_str=Unknown,fdest=1,peer_tag=50, prog_ind=0,callingIE_present 1, src_route_label=, tgt_route_label= clid_transparent=0},callID=0x6408BD24)
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind:
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: type 0 , prot 1
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
02:05:19: ccCheckClipClir: calling number is: “585XXX50X0″, calling oct3a is: 0×81
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
02:05:19: Calling Party number is User Provided
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:
02:05:19: Leaving ccCheckClipClir
calling number is: “585XXX50X0″
calling oct3 is:  0×11
calling oct3a is: 0×81

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: (vdbPtr=0x6428E260, callInfo={called=90114411898X1XXX, calling=585XXX50X0, fdest=1 peer_tag=50}, callID=0x6408BD24)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: Increment call volume: 0
02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: current call volume: 1
02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry’s incoming TRUE.

02:05:19: //207/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incoming is FALSE

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: profileTable[0x653738A0], numBuckets[11], numEntries[0]

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: Invoking necessary profileTable updaters…

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: Updating profileTable[0x653738A0] with objects in container[0x6408896C]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[5] for the tag[6]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x653738A0], tdObject[0x65C89E68]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[0] for the tag[22]

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x653738A0], tdObject[0x638DCC78]

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager:

02:05:19: ccTDUtilDumpAllElemInProfileTab: profileTable[0x653738A0], numBuckets[11], numEntries[2]

02:05:19: Bucket { 0 } ——>0x638DCC78[0x0,t-22,l-12,d-0x638DCC98,m-4,u-7519,g-FACE0FFF]

02:05:19:

02:05:19: Bucket { 5 } ——>0x65C89E68[0x0,t-6,l-16,d-0x65C89E88,m-2,u-7519,g-FACE0FFF]

02:05:19:

.
.
.
.
.

02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: cid(207), st(SSA_CS_MAPPING),oldst(0), ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: src route label=, tgt route label= tg_label_flag 0×0
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: finalDest cllng(585XXX50X0), clled(90114411898X1XXX) tgt_route_label()tg_label_flag 0×0
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaCallSetupInd: cid(207), st(SSA_CS_CALL_SETTING),oldst(0), ev(24)dpMatchPeersMoreArg result= 0
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaDebugPeers: ssaSetupPeer cid(207) peer list: tag(1) called number (90114411898X1XXX) tag(104) called number (90114411898X1XXX) tag(105) called number (90114411898X1XXX)
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaSetupPeer: dialpeer tags in rotary= 1  104  105
02:05:19: //207/xxxxxxxxxxxx/SSAPP:50:-1/ssaSetupPeer: cid(207), destPat(90114411898X1XXX), matched(1), prefix(), peer(64A70EFC), peer->encapType (1)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallProceeding: (callID=0xCF, prog_ind=0×0)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest: (Inbound call = 0xCF, outbound peer =1, dest=,
params=0×64392138 mode=0, *callID=0×64392708, prog_ind = 0callingIE_present 1)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest:

02:05:19: ccCallSetupRequest numbering_type 0×80
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest:
02:05:19: ccCallSetupRequest: calling number is:585XXX50X0

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest: calling oct3a is:0×81

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: (vdbPtr=0x64852F88, dest=, callParams={called=90114411898X1XXX,called_oct3=0×80, calling=585XXX50X0,calling_oct3=0×11, calling_oct3a= 0×81, calling_xlated=false,  subscriber_type_str=Unknown, fdest=1, voice_peer_tag=1},mode=0×0, appl_call_id=, callingIE_present=1)

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
02:05:19: ccIFCallSetupRequestPrivate: src route label  tgt route label tg_label_flag 0×0

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:  vdbPtr type = 6

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: (vdbPtr=0x64852F88, dest=, callParams={called=90114411898X1XXX, called_oct3 0×80,  calling=585XXX50X0,calling_oct3 0×11, calling_oct3a 0×81, calling_xlated=false,  fdest=1, voice_peer_tag=1}, mode=0×0, xltrc=-5)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:
02:05:19: //208/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: not incoming entry
02:05:19: //208/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry’s incoming FALSE.
02:05:19: //208/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incoming is FALSE
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/cc_set_voice_port_value:
02:05:19: CC_IF_TELEPHONY: echo =0, playout = 0

02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccSaveDialpeerTag: (callID=0xCF, dialpeer_tag=1)
02:05:19: //208/xxxxxxxxxxxx/CCAPI/ccCallSetContext: (callID=0xD0, context=0x638F184C)
02:05:19: //207/xxxxxxxxxxxx/CCAPI/ccCallReportDigits: (callID=0xCF, enable=0×0)
02:05:19: //-1/xxxxxxxxxxxx/CCA

VG-FRNA-MON-3725#PI/ccTDConstructTDUsrContainer: usrContainer[0x64082410], magic[FACE0FFF]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0×64082410, tagID=19, dataSize=4, instID=0,modifier=1
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x638FB624], nxtElem[0x0], magic[0xFACE0FFF] tagID[19], dataLen[4], modif[1]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x638FB624] instID[0] into container[0x64082410]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructMultiInstHolderObject: multiHolder[0x653B1B44], nxtElem[0x0], magic[0xFACE0FFF], tagID[19], dataLen[0], modif[-1], numInst[0]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtPushInstToMultiInstHolder: Successful in pushing instance object[0x638FB624] into holder[0x653B1B44]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: profileTable[0x6566213C], numBuckets[11], numEntries[0]
02:05:19: //208/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: Invoking necessary profileTable updaters…
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: Updating profileTable[0x6566213C] with objects in container[0x64082410]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[6] for the tag[19]
02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x6566213C], tdObject[0x653B1B44]
02:05:19: //208/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager:
02:05:19: ccTDUtilDumpAllElemInProfileTab: profileTable[0x6566213C], numBuckets[11], numEntries[1]
02:05:19: Bucket { 6 } ——>0x653B1B44[0x0,t-19,m-1,g-FACE0FFF 0x638FB624,i-0<t-19,l-4,d-0x638FB644,m-1,u-7519,g-FACE0FFF> ]
02:05:19:

02:05:19: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDUsrContainer: Container[0x64082410]

02:05:19: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8  callref = 0x00B0

Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0×1181, ’585XXX50X0′
Plan:ISDN, Type:International
Called Party Number i = 0×80, ’4411898X1XXX’    <<< Number got changed at the gateway
Plan:Unknown, Type:Unknown
Cause i = 0×8281 – Unallocated/unassigned number   <<< The error is coming from provider side

It appears though that call manager is sending the correct number ’901144….’ but for some reason the Q931 debugs were showing number going out as ’44……’ without the prefix ’011′. I checked the dialpeers and there was no stripping or forward-digits restriction on it. To remove any doubt concerning dial peers, I  created an explicit 9011 dial peer with prefix 011 and assign it preference 1. Even that didn’t work and my call was going out without 011 and failing.

Looking closely at Q931 debugs I found something interesting:

Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0×1181, ’585XXX50X0′
Plan:ISDN, Type:International
Called Party Number i = 0×80, ’4411898X1XXX’
Plan:Unknown, Type:Unknown
Cause i = 0×8281 – Unallocated/unassigned number

The outgoing called number had plan and type ‘Unknown’. Though the same settings were working fine for other sites I thought to explicitly assign proper type and plan and see if that makes any difference.

I created a seperate translation rule and Voice translation profile and included it in POTS dial peer.

!
voice translation-rule 5
rule 1 // // type any international plan any isdn
!

voice translation-profile PRI-INTL
translate calling 3
translate called 5
!

!
dial-peer voice 9011 pots
translation-profile outgoing PRI-INTL
preference 1
destination-pattern 9011T
progress_ind alert enable 8
progress_ind progress enable 8
progress_ind connect enable 8
port 2/0:23
prefix 011
!

Now when I dialled the number, it worked like a charm:

19:21:26: ISDN Se2/0:23 Q931: TX -> SETUP pd = 8  callref = 0×0147
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0×1181, ’585XXX50X0′
Plan:ISDN, Type:International
Called Party Number i = 0×91, ’4411898X1XXX’
Plan:ISDN, Type:International

19:21:26: ISDN Se2/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0×8147
Channel ID i = 0xA98397
Exclusive, Channel 23
19:21:28: ISDN Se2/0:23 Q931: RX <- ALERTING pd = 8  callref = 0×8147
Progress Ind i = 0×8488 – In-band info or appropriate now available
19:21:33: ISDN Se2/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0×0147
Cause i = 0×8090 – Normal call clearing
19:21:33: ISDN Se2/0:23 Q931: RX <- RELEASE pd = 8  callref = 0×8147
19:21:33: ISDN Se2/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0×0147

Provider was expecting proper type and plan and even though the call was still going without prefix ’011′ but it was working.

Advertisements

The setting below applies to packets generated by the router itself.

For H323 gateways

Default for signaling is af31 (26). Need to change this to cs3 (24).

dial-peer voice 1500 voip
ip qos dscp cs3 signaling 

For MGCP gateways

mgcp ip qos dscp cs3 signaling

$ means ”end of digits” and is used for a more specific match. If you have two dial-peers with the same pattern and one with $ and the other without $, then call routing logic will always match the one with $, because that is more specific. Even if you give a lower preference to the dial-peer with $, still it will be matched because by default the dial-plan hunting algorithm is more specific match first and then preference.

dial-peer voice 10 pots

destination-pattern 1000

port 1/0/0

dial-peer voice 11 pots

destination-pattern 1000$

port 1/0/0

preference 5

 

In this case, always dial-peer 11 will be used to route calls to 1000, even though it has a lower preference.