cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3007
Views
20
Helpful
17
Replies

Force an extension to exit a specific dial-peer.

jrblanquez
Level 1
Level 1

Hi.
I have an ISR 4321 cisco with 2 SIP trunk from the same provider (different dns and assigned numbers of course). Therefore, I would like specific extensions to go through specific dial-peers that point to SIP trunks that have the corresponding output number. How can I achieve this? I tried for preferences and it didn't work. Is there any way that I can classify the source extension and redirect calls to a dial-peer?

 

Thanks.

1 Accepted Solution

Accepted Solutions

I'm not entirely sure as you've obscured the actual destination patterns, but I think you may be expecting the destination patterns of DP 10, 11, 20 and 21 to distinguish National from International calls.  They won't.  If the call is routed by Dial Peer Group the outgoing dial peer's destination pattern is not used.  Selection is based on group membership and priority only.  When I use DPGs I generally give a destination pattern that's clearly nonsense just so that anyone viewing the configuration is not misled.

If you want separate National and International dial peers, maybe Class of Restriction is the way to go.  Set up COR on the incoming and out going dial peers such that a call received on say DP 100 can only "see" DP 10 and 11, but dial peer selection will still be based on dialled number.

View solution in original post

17 Replies 17

This is only party of the solution though right? They would still need to match based on the calling extension, in order to apply the correct incoming dial-peer to the call, before the DPG is used.

As seen here:
https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html#anc8

Inbound dial-peer matching by calling number is third preference and can be achieved with either:

1) incoming calling e164-pattern-map <pattern-map-number>
2) answer-address <number-string>

Once inbound is match, then yes, the DPG applied to that inbound DP would be the next piece.

Yes, inbound dial-peer has to be matched to trigger the DPG.  Depending on difference between the 2 incoming calls URI class can be used, i.e. using VIA if coming from difference SIP SBCs, To if destined to different CUBE interface. etc. If all calls come from same SBCs to the same CUBE interface then we would need to know what the distinction is, if for example it's based on called number then you can use incoming called-number with applied e164-map, etc.

 

Hi @Chris Deren and @Anthony Holloway . First of all thank you very much for your answers.

From what explain to me, I must make a mixture of both comments. After reading the documents sent to me, I think there would be something like this:

 

 

dial-peer voice 10 voip
destination-pattern xxxx (National calls)
session target dns1

dial-peer voice 11 voip
destination-pattern xxxx (International Calls)
session target dns1

dial-peer voice 20 voip
destination-pattern xxxx (National calls)
session target dns2

dial-peer voice 21 voip
destination-pattern xxxx (International Calls)
session target dns2


voice class e164-pattern-map 1
description E164 Pattern Map for calling internal extensions
e164 19.$
e164 20[2-9]$
e164 2[1-9].$


***There are specifics internal extensions that I want route to second SIP **

voice class e164-pattern-map 2
description E164 Pattern Map for calling internal extensions
e164 20[0-1]$


voice class dpg 1
dial-peer 10 preference 1
dial-peer 11 preference 2

 

dial-peer voice 100 voip
destination calling e164-pattern-map 1
destination dpg 1


voice class dpg 2
dial-peer 20 preference 1
dial-peer 21 preference 2


dial-peer voice 200 voip
destination calling e164-pattern-map 1
destination dpg 2

 

 

I have to test in my ISR, so I just that yours can check it.

 

Regards.

Technically your destination patterns on dial-peers 10, 11, 20, and 21 will not do anything. DPG's ignore them, though if you want SIP OPTIONs to still ping out to the peer, you do need some kind of destination-pattern to make the dial-peer act as an outgoing dial-peer.

Hi @Anthony Holloway 

 

Do you say it for xxx? It is only referential, in that field the corresponding destination numbers will go. I did it as an example

No, I could tell that was only an example pattern. What I mean is, when using DPGs, it ignores your destination patterns. So, while they are not used, they are still needed, if you are enabling SIP OPTIONS on that peer, to mark it busyout if the SIP peer on the far end goes dark.

Sorry friend @Anthony Holloway , I don´t understand to you.


 should not be the dial-peer 10,11,20 & 21 for output?

The thing I'm trying to tell you can be illustrated below.  Imagine a caller dials the number 3000, the construct below will still work, and will route the call for the caller, despite the destination pattern being 2000.  Note: Not all dial-peer config shown, just the bits needed to illustrate the point.

 

voice class dpg 2
 dial-peer 2
!

dial-peer voice 1 voip
incoming called-number . destination dpg 2 ! dial-peer voice 2 voip destination-pattern 2000 !

Hi @Anthony Holloway thanks for your answer.

 

I understand now your point. But according my propose configuration, do you agree?

 

Merry Christmas

Well, no, because you'll lose your different classes of service. With preferencing DP 10 over DP 11, all of your International calls will go out DP10. If that's ok with you, then you don't even need DP11 at all, as it provides zero benefit. Same thing with 20 and 21.

Hi @Anthony Holloway 

 

Oh no ... What I am trying to do with this configuration is that if the incoming call is from the specific internal extensions choose the dial-peer 100 input and the dial-peer 10 & 11 output, for national and international calls respectively by the SIP trunk 1 .
In the case of the extensions that I require, go out the SIP trunk 2, my idea is to choose the dial-peer 200 input and the dial-peer 20 & 21 output for national and international calls respectively.

 

Maybe I should change it as follows, according yours comments:

 

dial-peer voice 10 voip
destination-pattern xxxx (National calls through SIP 1)
session target dns1

 

dial-peer voice 11 voip
destination-pattern xxxx (International Calls through SIP 1)
session target dns1

 

dial-peer voice 20 voip
destination-pattern xxxx (National calls through SIP 2)
session target dns2

 

dial-peer voice 21 voip
destination-pattern xxxx (International Calls through SIP 2)
session target dns2

 

voice class dpg 1
dial-peer 10 preference 1
dial-peer 11 preference 1

 

dial-peer voice 100 voip
incoming calling e164-pattern-map 1
destination dpg 1


voice class dpg 2
dial-peer 20 preference 1
dial-peer 21 preference 1


dial-peer voice 200 voip
incomimg calling e164-pattern-map 1
destination dpg 2

 

 

 

Regards.

I'm not entirely sure as you've obscured the actual destination patterns, but I think you may be expecting the destination patterns of DP 10, 11, 20 and 21 to distinguish National from International calls.  They won't.  If the call is routed by Dial Peer Group the outgoing dial peer's destination pattern is not used.  Selection is based on group membership and priority only.  When I use DPGs I generally give a destination pattern that's clearly nonsense just so that anyone viewing the configuration is not misled.

If you want separate National and International dial peers, maybe Class of Restriction is the way to go.  Set up COR on the incoming and out going dial peers such that a call received on say DP 100 can only "see" DP 10 and 11, but dial peer selection will still be based on dialled number.

Hi @TONY SMITH , thanks for you reply.

 

I understand your point. I´ll check Class of restriction, and I´ll come back to leave you my comments.

 

Really thanks