Incoming DiD's looping

phoeneousphoeneous Member Posts: 2,333 ■■■■■■■□□□
I'm testing an h323 gateway (2911) that will go into production soon. I'm seeing something strange when I call our DiD's provisioned from provider. Provider is sending 10 digits and I've confirmed with debug isdn q931.

Consider the following dp's:

dial-peer voice 1 pots
trunkgroup PRI-01
description [< catch-all from PSTN
incoming called-number .
direct-inward-dial
!
dial-peer voice 21 pots
trunkgroup PRI-01
description [< Voice 312 10D local
destination-pattern 312[2-9]......
prefix 312

When I call 3125551212, this happens:

2911_gateway#sh voice call stat
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
No active calls found

2911_gateway#sh voice call stat
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x10D4 1908 0x32F9D0AC 0/0/0:23.1 0/1:1 3125551212 None 1/21
0x10D5 1908 0x32F9D0AC 0/0/0:23.23 0/1:2 *3125551212 None 21/1
1 active call found

2911_gateway#sh voice call stat
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x10D4 1908 0x32F9D0AC 0/0/0:23.1 0/1:1 3125551212 None 1/21
0x10D5 1908 0x32F9D0AC 0/0/0:23.23 0/1:2 *3125551212 None 21/1
0x10D6 1909 0x32F9D0AC 0/0/0:23.2 0/1:3 3125551212 None 1/21
0x10D7 1909 0x32F9D0AC 0/0/0:23.22 0/1:4 *3125551212 None 21/1
0x10D8 190A 0x32F9D0AC 0/0/0:23.3 0/1:5 3125551212 None 1/21
0x10D9 190A 0x32F9D0AC 0/0/0:23.21 0/1:6 *3125551212 None 21/1
0x10DA 190B 0x32F9D0AC 0/0/0:23.4 0/1:7 3125551212 None 1/21
0x10DB 190B 0x32F9D0AC 0/0/0:23.20 0/1:8 *3125551212 None 21/1
4 active calls found

2911_gateway#sh voice call stat
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x10D4 1908 0x32F9D0AC 0/0/0:23.1 0/1:1 3125551212 None 1/21
0x10D5 1908 0x32F9D0AC 0/0/0:23.23 0/1:2 *3125551212 None 21/1
0x10D6 1909 0x32F9D0AC 0/0/0:23.2 0/1:3 3125551212 None 1/21
0x10D7 1909 0x32F9D0AC 0/0/0:23.22 0/1:4 *3125551212 None 21/1
0x10D8 190A 0x32F9D0AC 0/0/0:23.3 0/1:5 3125551212 None 1/21
0x10D9 190A 0x32F9D0AC 0/0/0:23.21 0/1:6 *3125551212 None 21/1
0x10DA 190B 0x32F9D0AC 0/0/0:23.4 0/1:7 3125551212 None 1/21
0x10DB 190B 0x32F9D0AC 0/0/0:23.20 0/1:8 *3125551212 None 21/1
0x10DC 190C 0x32F9D0AC 0/0/0:23.5 0/1:9 3125551212 None 1/21
0x10DD 190C 0x32F9D0AC 0/0/0:23.19 0/1:10 *3125551212 None 21/1
0x10DE 190D 0x32F9D0AC 0/0/0:23.6 0/7:1 3125551212 None 1/21
0x10DF 190D 0x32F9D0AC 0/0/0:23.18 0/7:2 *3125551212 None 21/1
6 active calls found

2911_gateway#sh voice call stat
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x10D4 1908 0x32F9D0AC 0/0/0:23.1 0/1:1 3125551212 None 1/21
0x10D5 1908 0x32F9D0AC 0/0/0:23.23 0/1:2 *3125551212 None 21/1
0x10D6 1909 0x32F9D0AC 0/0/0:23.2 0/1:3 3125551212 None 1/21
0x10D7 1909 0x32F9D0AC 0/0/0:23.22 0/1:4 *3125551212 None 21/1
0x10D8 190A 0x32F9D0AC 0/0/0:23.3 0/1:5 3125551212 None 1/21
0x10D9 190A 0x32F9D0AC 0/0/0:23.21 0/1:6 *3125551212 None 21/1
0x10DA 190B 0x32F9D0AC 0/0/0:23.4 0/1:7 3125551212 None 1/21
0x10DB 190B 0x32F9D0AC 0/0/0:23.20 0/1:8 *3125551212 None 21/1
0x10DC 190C 0x32F9D0AC 0/0/0:23.5 0/1:9 3125551212 None 1/21
0x10DD 190C 0x32F9D0AC 0/0/0:23.19 0/1:10 *3125551212 None 21/1
0x10DE 190D 0x32F9D0AC 0/0/0:23.6 0/7:1 3125551212 None 1/21
0x10DF 190D 0x32F9D0AC 0/0/0:23.18 0/7:2 *3125551212 None 21/1
0x10E0 190E 0x32F9D0AC 0/0/0:23.7 0/7:3 3125551212 None 1/21
0x10E1 190E 0x32F9D0AC 0/0/0:23.17 0/7:4 *3125551212 None 21/1
0x10E2 190F 0x32F9D0AC 0/0/0:23.8 0/7:5 3125551212 None 1/21
0x10E3 190F 0x32F9D0AC 0/0/0:23.16 0/7:6 *3125551212 None 21/1
8 active calls found

2911_gateway#sh voice call stat
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x10D4 1908 0x32F9D0AC 0/0/0:23.1 0/1:1 3125551212 None 1/21
0x10D5 1908 0x32F9D0AC 0/0/0:23.23 0/1:2 *3125551212 None 21/1
0x10D6 1909 0x32F9D0AC 0/0/0:23.2 0/1:3 3125551212 None 1/21
0x10D7 1909 0x32F9D0AC 0/0/0:23.22 0/1:4 *3125551212 None 21/1
0x10D8 190A 0x32F9D0AC 0/0/0:23.3 0/1:5 3125551212 None 1/21
0x10D9 190A 0x32F9D0AC 0/0/0:23.21 0/1:6 *3125551212 None 21/1
0x10DA 190B 0x32F9D0AC 0/0/0:23.4 0/1:7 3125551212 None 1/21
0x10DB 190B 0x32F9D0AC 0/0/0:23.20 0/1:8 *3125551212 None 21/1
0x10DC 190C 0x32F9D0AC 0/0/0:23.5 0/1:9 3125551212 None 1/21
0x10DD 190C 0x32F9D0AC 0/0/0:23.19 0/1:10 *3125551212 None 21/1
0x10DE 190D 0x32F9D0AC 0/0/0:23.6 0/7:1 3125551212 None 1/21
0x10DF 190D 0x32F9D0AC 0/0/0:23.18 0/7:2 *3125551212 None 21/1
0x10E0 190E 0x32F9D0AC 0/0/0:23.7 0/7:3 3125551212 None 1/21
0x10E1 190E 0x32F9D0AC 0/0/0:23.17 0/7:4 *3125551212 None 21/1
0x10E2 190F 0x32F9D0AC 0/0/0:23.8 0/7:5 3125551212 None 1/21
0x10E3 190F 0x32F9D0AC 0/0/0:23.16 0/7:6 *3125551212 None 21/1
0x10E4 1910 0x32F9D0AC 0/0/0:23.9 0/7:7 3125551212 None 1/21
0x10E5 1910 0x32F9D0AC 0/0/0:23.15 0/7:8 *3125551212 None 21/1
0x10E6 1911 0x32F9D0AC 0/0/0:23.10 0/7:9 3125551212 None 1/21
0x10E7 1911 0x32F9D0AC 0/0/0:23.14 0/7:10 *3125551212 None 21/1
0x10E8 1912 0x32F9D0AC 0/0/0:23.11 0/7:11 3125551212 None 1/21
0x10E9 1912 0x32F9D0AC 0/0/0:23.13 0/7:12 *3125551212 None 21/1
11 active calls found

As soon as the call comes in, it immediately dials back out, and continues to loop until all channels are full. What would cause that?

It seems that the only way I can get inbound 312xxxxxxx DiD's to ring correctly is to include forward-digits 0 and remove prefix 312:

dial-peer voice 21 pots
trunkgroup PRI-01
description [< Voice 312 10D local
destination-pattern 312[2-9]......
forward-digits 0

Thoughts?

Comments

  • shodownshodown Member Posts: 2,271
    do a debug voip ccapi inout
    Currently Reading

    CUCM SRND 9x/10, UCCX SRND 10x, QOS SRND, SIP Trunking Guide, anything contact center related
  • pitviperpitviper Member Posts: 1,376 ■■■■■■■□□□
    Yeah, looks like you’re “tromboning” the call and sending it back out dial-peer 21. Do you have a dial-peer to send the call to a CM?
    CCNP:Collaboration, CCNP:R&S, CCNA:S, CCNA:V, CCNA, CCENT
  • phoeneousphoeneous Member Posts: 2,333 ■■■■■■■□□□
    shodown wrote: »
    do a debug voip ccapi inout
    Yes

    dial-peer voice 100 voip
    description ***PUB_CM***
    preference 1
    destination-pattern .
    progress_ind setup enable 3
    session target ipv4: pub.ip
    incoming called-number .
    voice-class codec 99
    voice-class h323 1
    dtmf-relay rtp-nte h245-signal h245-alphanumeric
    ip qos dscp cs3 signaling
    no vad

    When I have dp 21 set to forward-digits 0, dp 100 matches and call is translated by cm.
  • aaron0011aaron0011 Member Posts: 330
    pitviper wrote: »
    Yeah, looks like you’re “tromboning” the call and sending it back out dial-peer 21. Do you have a dial-peer to send the call to a CM?

    This. Why are you prefixing dial peer 21 with 312?

    Also, create a voip dial peer with same the destination pattern as dial peer 21 and point it to CUCM.
  • phoeneousphoeneous Member Posts: 2,333 ■■■■■■■□□□
    aaron0011 wrote: »
    This. Why are you prefixing dial peer 21 with 312?

    Also, create a voip dial peer with same the destination pattern as dial peer 21 and point it to CUCM.

    Because when I don't, I am unable to do 10 digit local dialing to 312 area code. Unless there is something in the cm route pattern that I missed but I've mimicked this config to another site that is basically setup the same way.
  • pitviperpitviper Member Posts: 1,376 ■■■■■■■□□□
    phoeneous wrote: »
    Because when I don't, I am unable to do 10 digit local dialing to 312 area code. Unless there is something in the cm route pattern that I missed but I've mimicked this config to another site that is basically setup the same way.

    the same doesn't necessarily = "correct" :)

    Is there a reason why the provider is sending the full 10 digits? Much easier to work with 4-6 digits. I would translate them @ the gateway to make the CUCM config much cleaner (assuming you can't get them to send less). Also, if using a 9 or equivalent for outside access send the 9 to the gateway and strip it off as it leaves the dial peer. This will solve your in/out dial-peer selection issue.
    CCNP:Collaboration, CCNP:R&S, CCNA:S, CCNA:V, CCNA, CCENT
  • phoeneousphoeneous Member Posts: 2,333 ■■■■■■■□□□
    pitviper wrote: »
    the same doesn't necessarily = "correct" :)

    Is there a reason why the provider is sending the full 10 digits? Much easier to work with 4-6 digits. I would translate them @ the gateway to make the CUCM config much cleaner (assuming you can't get them to send less). Also, if using a 9 or equivalent for outside access send the 9 to the gateway and strip it off as it leaves the dial peer. This will solve your in/out dial-peer selection issue.

    And that's what lead to our solution. Since the problem gateway was receiving 10 digits, and known working gateway is receiving 4, we had to do some work with translations at the gateway level.
  • aaron0011aaron0011 Member Posts: 330
    Can you post all of the voice elements from the config of the problem gateway? Seeing all of the dial peers and translations would give us a better idea of what exactly is causing the loop.
  • aaron0011aaron0011 Member Posts: 330
    phoeneous wrote: »
    Because when I don't, I am unable to do 10 digit local dialing to 312 area code. Unless there is something in the cm route pattern that I missed but I've mimicked this config to another site that is basically setup the same way.

    I follow you on the prefix. This is because pots dial peers strip off all explicit digits.

    Your loop is happening because the pots dial peer is matching before voip dial peer. Set your RP for these local 10D calls in CUCM to send the 9 to the gateway. Then configure dial peer 21 like this and the prefix won't be needed.

    dial-peer voice 21 pots
    trunkgroup PRI-01
    description [< Voice 312 10D local
    destination-pattern 9T
Sign In or Register to comment.