cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1062
Views
5
Helpful
5
Replies

VOIP inbound dial-peer logic question

v_bashaev
Level 1
Level 1

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.

5 Replies 5

Felipe Garrido
Cisco Employee
Cisco Employee

You are correct. Inbound dial-peers will not match based on protocol. They will match as per the following document.

http://www.cisco.com/en/US/customer/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml#topic1


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

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.

Steven Holl
Cisco Employee
Cisco Employee

There are a couple other options to what Felipe mentioned:

a) Remove all 'incoming called-number' statements with implicit matches, and use 'answer-address ' instead.  This will only work if you know the ANI blocks from each source, and if they are different.

b) Upgrade to 15.1(2)T where you can do inbound dial-peer matching based on source IP address.

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).

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 ' instead of 'incoming-called number ' for specifying how inbound voip peers are matched.

Getting Started

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: