08-24-2010 05:56 AM - edited 03-16-2019 12:26 AM
Hi and my best wishes to all forum users!
I have a question regarding IOS voice gateway inbound dial-peer logic.
Suppose, my gateway needs to receive calls to the same destination from different voip peers,
some on h.323 and some on sip, and apply different processing to them.
If I have 2 dial-peers like:
dial-peer voice 10 voip
incoming called-number 123
session-protocol sip
codec g729br8
...
and
dial-peer voice 11 voip
incoming called-number 123
codec g711u
will the gateway diffrentiate between them based on call setup session protocol proposal?
Or more generally, can I have multiple incoming voip dial-peers with the same 'incoming called-number' configured and if I can
how the gateway will choose one to use?
I haven't worked with such problems for quite a while, but my today's expiriments guide me to preliminary conclusion that
the gateway will just pick the first configured dial-peer statement and send 'bcap not implemented' if protocol/codec of incoming call
don't match configured in this first statement.
Would appreciate any tips.
08-24-2010 06:28 AM
You are correct. Inbound dial-peers will not match based on protocol. They will match as per the following document.
I would advise using different prefixes, added by the originating device, to differentiate between the two different types of calls. Then use voice translation rules/profiles, if in a IP-IP environment, or if matching an outbound pots dial-peer, the forward-digits command or explicit matching on the destionation-pattern, to remove the prefix before sending the call to the next device.
For example,
SIP calls get prefixed with a 9.
H.323 calls get prefixed with an 8.
Called party number 123
SIP dial-peers,
dial-peer voice 1 voip
incoming called-number 9...
dial-peer voice 2 pots
destination-pattern 9...
port x/y
If IP-IP scenario,
voice translation-rule 1
rule 1 /^9\(.../)/ /\1/
voice translation-profile strip9
translate called 1
dial-peer voice 3 voip
translation-profile outgoing strip9
destination-pattern 9...
For H.323 you'd just change the prefix to an 8
SIP dial-peers,
dial-peer voice 1 voip
incoming called-number 8...
dial-peer voice 2 pots
destination-pattern 8...
port x/y
If IP-IP scenario,
voice translation-rule 1
rule 1 /^8\(.../)/ /\1/
voice translation-profile strip8
translate called 1
dial-peer voice 3 voip
translation-profile outgoing strip8
destination-pattern 8...
For more information on voice translation rules,
http://www.cisco.com/en/US/customer/tech/tk652/tk90/technologies_tech_note09186a0080325e8e.shtml
-Felipe
08-24-2010 06:40 AM
Thanks for reply.
That's the obvious solution and the one I have as a backup plan because there will be a lot of devices to reconfigure if I go that way.
My question was more about logic of selecting inbound voip dial-peer.
08-24-2010 06:43 AM
There are a couple other options to what Felipe mentioned:
a) Remove all 'incoming called-number' statements with implicit matches, and use 'answer-address
b) Upgrade to 15.1(2)T where you can do inbound dial-peer matching based on source IP address.
08-24-2010 07:11 AM
Thanks for reply!
Looks like a cute feature int 151(2)T, but it's not easy to upgrade I think.
I haven't quite got your point: "Inbound dial-peer matching logic does NOT look at the protocol. It will take ALL voip peers into consideration."
If it will consider all voip peers configured for the same incoming called-number, how will it pick one? (if not just the first one, which I supposed).
08-24-2010 07:30 AM
If it will consider all voip peers configured for the same incoming
called-number, how will it pick one? (if not just the first one, which I
supposed).
Let me give an example. Say you have:
dial-peer voice 1 voip
dtmf-relay h245-alpha
session target 10.1.1.1
incoming called-number 2112
dial-peer voice 2 voip
dtmf-relay rtp-nte
session protocol sipv2
session target 10.1.10.10
incoming called-number 2112
A SIP call from 10.1.10.10 and ANI of 2112 will randomly match dial-peers 1 and 2. One call may match peer 1, and the next identical call may match peer 2. Both are equal matches as far asthe algorithm goes, so it is random selection between 1 and 2 at that point. The call control API is not aware of what protocol the call came in on when matching an inbound dial-peer. Same goes with an inbound h323 call from 10.1.1.1. It may match peer 1, it may match peer 2.
You can run 'debug voice dialpeer all' during a call if you want to see the details of how the logic actually occurs.
Yes, the upgrade to get dial-peer binding will require you have the memory to support that, and that you are running a box where that train is supported.
If you don't want t upgrade, and if Felipe's configuraiton is too much configuration for you, then I suggest you make it so your different inbound calls from the VoIP side come in with different ANIs, and you use 'answer-address
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: