seperate 2 number ranges on outboudn dialpeer

[Scott Brien]

Hi,

We currently have 2 SIP trunks which are used for seperate number ranges which are not able to communicate with each other by use of CSS/partitions.

However we would like to use Cisco unified border element instead of SIP trunks terminating directly on our UCMs.

Is there a way which i can have 2 seperate number ranges be sent to 2 completely seperate dial peers so they do not get sent to the wrong provider

here is the sample for the dial peers configured:

dial-peer voice 10 voip
description -- Outbound to Provider SBC
destination-pattern 0T
session protocol sipv2
session target ipv4:1A.B.C.D
voice-class sip asserted-id pai
dtmf-relay rtp-nte
codec g711ulaw
no vad

dial-peer voice 11 voip
description -- Outbound to Provider SBC
destination-pattern 0T
session protocol sipv2
session target ipv4:w.x.y.z
voice-class sip asserted-id pai
dtmf-relay rtp-nte
codec g711ulaw
no vad

Any help on this issue would be greatly appreciated.

Regards,

Scott

[paolo bevilacqua]

Yes, that is done with COR or number maniupulation base on answer-address on incoming DP.

Are you a network engineer or the end-user ?

[Scott Brien]

Hi,

I am network engineer and new to the voice side of things.

With the configuration of cor lists would I write a rule saying xx number range outbound via dial peer 10 and xx range outbound via dial peer 11

Regards,

Scott

[paolo bevilacqua]

Yes.

[William Bell · Accepted solution]

I assume that by "two separate number ranges" you mean the DIDs assigned to your station lines?  IOW, the phone numbers assigned to users?

In the pre-cube scenario you probably leverage separate Calling Search Spaces on phones/lines that use separate patterns - Route Lists/Gateways.

In the post-cube scenario you could follow the same basic logic.  While you can solve this with dial-peer configs solely (using answer-address), this isn't my preference.  I prefer to handle it from the CUCM side of the house.  I prefer to use prefixes. 

Example:

Tenant-A:  Prefix 101

Tenant-B:  Prefix 102

RouteListA

- Contains RouteGroupA and is configured to Prefix 101 on called party information

RouteListB

- Contains RouteGroupB and is configured to Prefix 102 on called party information

*With the above config on CUCM, the goal is that the CUCM provides "direction" to the CUBE router via a 3-digit prefix (you can use a 2d if you like).  You will want your prefix digits to be unique within your CUBE dial-plan.  We use dial-peers on the CUBE to control routing to the carrier.*

CUBE:

voice translation-rule 10

rule 1 /^101/ //

rule 2 /^102/ //

!

voice translation-profile egressTranslation

translate called 10

!

dial-peer voice 10 voip

description -- Outbound to Provider SBC

destination-pattern 1010T

*translation-profile outgoing egressTranslation*

session protocol sipv2

session target ipv4:1A.B.C.D

voice-class sip asserted-id pai

dtmf-relay rtp-nte

codec g711ulaw

no vad

!

dial-peer voice 11 voip

description -- Outbound to Provider SBC

destination-pattern 1020T

*translation-profile outgoing egressTranslation*

session protocol sipv2

session target ipv4:w.x.y.z

voice-class sip asserted-id pai

dtmf-relay rtp-nte

codec g711ulaw

no vad

!

The voice-translation items I show above are intended to strip the 3-digit prefix before you send the call setup to the carrier.  This is necessary because SBC will have no clue what 101 or 102 mean.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

[Scott Brien]

Hi William,

yes your assumptions are correct in the way we have these 2 tennants set up.

This way seems like a decent way of seperating tennants i will test this in the next outage for testing and let you know how it goes.

Thanks

Scott

[Scott Brien]

Hi William,

Got around to finishing off this project, those translation patterns worked very.

Thank you for your assistance.

Regards,

Scott