I think I got the answer. I suppose this problem is there since day 1.
Never encounter this before as those dial-peer towards PSTN usually I will
put 9T.
In this specific gateway, it's .T .
New learning experience for me.
On Mon, Aug 14, 2017 at 1:22 PM, Ki Wi wrote:
> Hi Brian/Sreekanth,
> thanks for the recommendation.
>
> The managed service guys gotten the fix from TAC using
> 1) "no voice hunt unassigned-number"
> 2) "huntstop" on dial-peer level.
>
> Previously when I was dealing with h323 or mgcp, this problem doesn't
> seems to be there?
>
> Is it something new due to SIP gateway configuration?
>
>
> On Mon, Aug 14, 2017 at 11:46 AM, Sreekanth wrote:
>
>> Have you tried the 'huntstop' command on DP 200 so that the IOS stops
>> hunting for more dial-peers after matching DP 100 and DP 200?
>>
>> On 14 August 2017 at 09:09, Brian Meade wrote:
>>
>>> You can do things like "no voice hunt unassigned-number" and "no voice
>>> hunt invalid-number" on IOS to keep it from trying more dial-peers.
>>>
>>> On Sun, Aug 13, 2017 at 10:47 PM, Ki Wi wrote:
>>>
Hi Group,
I have encountered this interesting problem on customer PBX. Didn't
work on live system for a long time but I am pretty sure this shouldn't be
a default behavior.
When external PSTN caller calls an unassigned number in the DID range,
CUCM returns with error code 27 ( destination out of order).
This causes the voice gateway to retry other dial-peers.
There's 3 dial-peer which matches this e164 number.
1)Dial-peer 100 goes CUCM (longest match, most specific)
2)Dial-peer 200 goes CUCM (longest match, most specific)
3)Dial-peer 300 goes to PSTN (the destination-pattern is .T)
When dial-peer 100 and 200 "fails", the voice gateway will dial-out to
PSTN via dial-peer 300. Once again, PSTN route back to the customer VG.
This causes a routing loop and it can fills up all the available E1
channels quickly.
*Just wondering if anyone encounter the following issue and have a
explanation to it? Just the engineering side of me want to get down to the
root cause. *
The CUCM have "stop routing on unallocated number" turns off (false).
Just in case it matters.
I tried to google around but can't seems to find any article that talks
about
1) dial-peer behaviors (on voice gateway side) - on what error code
will cisco voice gateway retry other dial-peers?
2) why CUCM returns error code 27?
It's a managed service system so I'm unable to do a deep dive
troubleshooting.
The current workaround introduced is to create a dial-peer 250 with a
higher preference that matches the DID range and block it.
This means that incoming dialed number will match to 4 dial-peers (100,
200, 250 and 300)
After failing on 100 and 200, the call gets block on dial-peer 250.
--
Regards,
Ki Wi
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
>
> --
> Regards,
> Ki Wi
>
--
Regards,
Ki Wi
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip