Outbound dial-peer selection

[Boyan Sotirov]

I've been playing around lately with the following TEHO setup (a recriation of one of the CVOICE 8 labs from the Lab Guide):

HQ router connected over a FR PVC to an BR router. The BR router also has an E1 connection to another router simulatin PSTN connectivity.

The dialplan on the HQ router is from a european country, the BR uses NANP.

With the TEHO implementation I configura an outbound SIP dial-peer with an access code 00066T. This call than should be routed to the BR router where it hops off to the PSTN (the calling numer is correctly preformated as an international number).

I followed exactly the configs from the Lab Guide and it works, but only if the called number from the HQ router is in the format 000664554551000# (455 or any such sequence). If I dial 000661233211000# for example, the local pots dial-peer is selected and the call is routed over the E1 connection to the PSTN, so there's no TEHO. I'm completely confused by this as the dial-pattern to me is the same. And when I use debug voip dialpeer detail during a call I see that at first the correct dial-peer is selected, but than something happens and the HQ router selects the POTS dial-peer. I don't get the logic here.

Here is the respective configuration on the HQ router and below some debugs:

HQ-1#show dial-peer voice summary

dial-peer hunt 0

             AD                                    PRE PASS                OUT

TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE

7      pots  up   up             0[2-9]......       0                      up   0/2/0:15

10     pots  up   up             00[2-9].........   0                      up   0/2/0:15

9011   pots  up   up   00        000T               0                      up   0/2/0:15

112    pots  up   up             112                0                      up   0/2/0:15

1120   pots  up   up             0112               0                      up   0/2/0:15

1      pots  up   up                                0                      down

6600   voip  up   up             00066T             0  syst ipv4:10.1.250.102  

555    voip  up   up             5552...            0  syst ipv4:10.1.250.102

!

voice translation-rule 6

rule 1 /^2/ /555115552/ type any international

! 

!

voice translation-rule 8

rule 1 /^00066/ /91/ ! this formating is needed for the BR router to correctly route the call over the E1 line

!

!

voice translation-profile teho-out

translate calling 6

translate called 8

!

!

dial-peer voice 10 pots

corlist outgoing national-out

destination-pattern 00[2-9].........

port 0/2/0:15

forward-digits 11

!

dial-peer voice 9011 pots

corlist outgoing intl-out

destination-pattern 000T

port 0/2/0:15

prefix 00

!

!

dial-peer voice 6600 voip

translation-profile outgoing teho-out

destination-pattern 00066T

session target ipv4:10.1.250.102

voice-class codec 1 

!

*May 16 09:19:22.255: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

   Match Rule=DP_MATCH_ORIGINATE; Calling Number=000663211231000

*May 16 09:19:22.255: //-1/xxxxxxxxxxxx/DPM/dpMatchCore:

   Dial String=, Expanded String=, Calling Number=000663211231000T

   Timeout=TRUE, Is Incoming=TRUE, Peer Info Type=DIALPEER_INFO_SPEECH

*May 16 09:19:22.255: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer:

   Result=Success(0); Incoming Dial-peer=9011 Is Matched

*May 16 09:19:22.255: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer:

   Result=Success(0); Incoming Dial-peer=6600 Is Matched

*May 16 09:19:22.255: //-1/xxxxxxxxxxxx/DPM/dpMatchCore:

   Dial String=000663211231000, Expanded String=000663211231000, Calling Number=

   Timeout=TRUE, Is Incoming=FALSE, Peer Info Type=DIALPEER_INFO_SPEECH

*May 16 09:19:22.255: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer:

   Result=Success(0); Outgoing Dial-peer=9011 Is Matched

*May 16 09:19:22.255: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer:

   Result=Success(0); Outgoing Dial-peer=6600 Is Matched

Even more confusing is:

*May 16 09:19:24.931: //-1/xxxxxxxxxxxx/DPM/dpMatchCore:

   Dial String=00663211231000, Expanded String=00663211231000, Calling Number=

   Timeout=TRUE, Is Incoming=FALSE, Peer Info Type=DIALPEER_INFO_SPEECH

*May 16 09:19:24.931: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer:

   Result=Success(0); Outgoing Dial-peer=10 Is Matched

According to my understanding (might be wrong anyway) the outbound dial-peer selection is based soley on the destination pattern. And the longest match should be selected. In this case this is 00066T. So whatever number I put after 00066, that dial-peer (dial-peer voice 6600) should be selected. But it doesn't happen that way... Maybe I don't interpret the debug output correctly, but at the end I see (in show call active voice brief) that when I dial 000664554551000# dial peer with id 6600 is selected, and when I dial 000661233211000# dial peer with id 9011 is selected.

[Ayodeji Okanlawon]

Boyan,

You are right its a bit of a strange one.

Can you do a test call again and send the fF:

'debug voip ccapi inout'

[Boyan Sotirov]

Hi Aokanalawon,

I did two tests with this debug switched on. The scenario is the following:

1. Good case: dialing from station 2002, destination number 000664554551000#. The text file debug_voip_ccapi_inout_good.txt contains the debug outputs.

2. Bad case: dialing from station 2002, destination number 000663211231000#. The file debug_voip_ccapi_inout_bad.txt contains the debug outputs.

Waht I see in the second case is that initially the correct output dial-peer is selected: i.e. 6600 (and all the correct digit manipulations are in place). But than something happens and the call is rerouted over the pots dialpeer 9011. You'll see also that the digit mainipulation is doen once again over the original calling number 2002, and the nuber is changed to 5552002. Which is correct, as I have an outbound translation rule confibured on voice-port 0/0/0:15 doing just that.

It seems to me that the call routing process for some reason starts all over again and dial-peer 99011 is selected. But I don't know why this happens...

Regards,

Boyan

[acampbell · Accepted solution]

Boyan,

On the BAD trace you are sending the call firstly through DP 6600

You are receiving back a Disconnect Cause 1

INVALID Number for the translated digits 913211231000

"

*May 16 12:01:58.223: //534/C1753CD5855A/CCAPI/ccSaveDialpeerTag:

   Outgoing Dial-peer=6600

*May 16 12:01:58.375: //535/C1753CD5855A/CCAPI/cc_api_call_disconnected:

  Cause Value=1, Interface=0x48F541F4, Call Id=535

*May 16 12:01:58.375: //535/C1753CD5855A/CCAPI/cc_api_call_disconnected:

   Call Entry(Responsed=TRUE, Cause Value=1, Retry Count=0)

*May 16 12:01:58.375: //534/C1753CD5855A/CCAPI/ccCallReleaseResources:

   release reserved xcoding resource.

*May 16 12:01:58.375: //535/C1753CD5855A/CCAPI/ccCallSetAAA_Accounting:

   Accounting=1, Call Id=535

*May 16 12:01:58.375: //535/C1753CD5855A/CCAPI/ccCallDisconnect:

   Cause Value=1, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=1)

*May 16 12:01:58.375: //535/C1753CD5855A/CCAPI/ccCallDisconnect:

   Cause Value=1, Call Entry(Responsed=TRUE, Cause Value=1"

The router is then rhunting and matching DP 9011

Have a look further down the line at the router/device 10.1.250.102

Is  DN 913211231000 valid

Regards,
Alex.
Please rate useful posts.

[Boyan Sotirov]

Alex,

You're absolutely right. I just did a trace on the remote router where the call should be terminated and indeed I see a call comming in, but it's regected.

I can't understand why though. Here's the dial-peer table I've got on that router:

BR-1#show dial-peer voice summary

dial-peer hunt 0

             AD                                    PRE PASS                OUT

TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE

7      pots  up   up             9[2-9]......       0                      up   0/2/0:15

10     pots  up   up   1         91[2-9]..[2-9]..-  0                      up   0/2/0:15

                                 ....

9011   pots  up   up   011       9011T              0                      up   0/2/0:15

911    pots  up   up             911                0                      up   0/2/0:15

9911   pots  up   up             9911               0                      up   0/2/0:15

1      pots  up   up                                0                      down

20005  pots  up   up             3001$              0                           50/0/1

             AD                                    PRE PASS                OUT

TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE

2000   voip  up   up             810....            0  syst ipv4:10.1.250.101  

2      voip  up   up                                0  syst                    

2005   pots  up   up             810....            2                      up   0/2/0:15

5500   voip  up   up             901155T            0  syst ipv4:10.1.250.101  

555    voip  up   up             5552...            0  syst ipv4:10.1.250.101  

I'm calling from 2002, which is modified to 555115552002. The dialed number is 000663211231000#, modified to 913211231000. So in this case this will not match dial-peer 10! Another test revieals that you're right. I dialed 000663213231000# and it works as expected. You're the man!

And I still have a lot to learn...

Regards,

Boyan

[Ayodeji Okanlawon]

Boyan,

Sorry I took a while was busy on some issues at work...OK alex has pointed why your first call was failing..Let me just shed some light

So this is what happened. Your call matched two potential DP. 00066T and 000T. The preferred dial-peer is 00066T because it has a longer match.

When this dial-peer was used the call failed, hence the gateway attempted to use the second dial-peer... This is why you see a new setup using the second dial-peer. The called numbe is different beacuse on dial-peer 00066T.. you have a xlation profile and on dial-peer 000T, you do not have any, so you see the orignal dialled number here

: Destination Pattern=00066T, Called Number=913211231000, Digit Strip=FALSE

Destination Pattern=000T, Called Number=000663211231000, Digit Strip=TRUE

The call is disconnected with cause value =1 which is unallocated un assigned number.  You need to send the trace for the other gateway..We need to see why its saying un allocated /un assgined number

[acampbell]

Boyan,

The destination pattern for DP 10 = 91[2-9]..[2-9]..

The dialled number = 913211231000

So starting with the 1st dialled digit lets use an M for MATCH

9M1M3M2M1M1--- BUT NOW A 1 DOES NOT MATCH [2-9] in the 6th position

So you could try changing the destination pattern

!

dial-peer voice  10 pots

destination-pattern 91[2-9].....

Regards,
Alex.
Please rate useful posts.

[Ayodeji Okanlawon]

Alex,

Great job on the forum!

Just wanted to say that this call is never going to macth DP=10. The called number is  000663213231000# and its only when it matches the dial-peer 6600 that its translated to  913211231000. At this point this dial-peer is already matched and the call will be routed out that dial-peer.

[Boyan Sotirov]

Thank you Alex and aokanlawon.

I noticed strange thing this morning when I got back in the office. I tried again my TEHO setup, and this time it showed something strange. The call was again disconnected from the BR router but this time the reason is something else:

*May 17 09:15:42.681: //569/B198B1AE85AC/CCAPI/ccCallDisconnect:

   Cause Value=65, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=65)

*May 17 09:15:42.681: //569/B198B1AE85AC/CCAPI/ccCallDisconnect:

   Cause Value=65, Call Entry(Responsed=TRUE, Cause Value=65)

I'm puzzled because I haven't changed anything on the configuration from yesterday.

What I found about Cause Code value 65 is:

"Bearer Capability Not Implemented.

Indicates that the equipment sending this cause does not support the bearer capability requested (i.e., requesting 64kb data when only speech is supported)."

Anyway. At least the configuration details of the TEHO setup are much clearer to me now. Thank you.

[Boyan Sotirov]

Well that's sloppy from my side!

I just figured it out. Yesterday evening I've removed the codec class associated with the inbound dial-peer on the BR router. So that's the reason I was getting Disconnect Cause Code 65. I've put it back in, and it works as expected now.

Regards,

Boyan