cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6840
Views
0
Helpful
8
Replies

Multiple SIP Trunks on Single CUBE

d.hillman
Level 1
Level 1

Is it possible to configure multiple SIP trunks on a single CUBE, while utilizing the same dial patterns and being selective of which trunk to utilize?

In other words, two SIP trunks terminated at the CUBE router. One trunk to be used for departments A and B, while the second trunk would be used by departments C and D. Also departments A, B, C, and D all utilize the same dial patterns (i.e. 9T)? I can not envision how this could be accomplished because it would make overlapping dial-peers.

- Misc Info

CM 7.0

Gateways are H.323 to CM

Thank you in advance for the advice.

1 Accepted Solution

Accepted Solutions

This is possible. What you would do here is use one of two things:

-Intermediary translations (tagging)

-Corlists

Matching an inbound dial peer for the 4 divisions isn't hard. You can have something like this:

dial-peer voice 1 voip

answer-address 1...

translation pattern (to prefix 1#)

dial-peer voice 2 voip

answer address 2...

translation pattern (to prefix 2#)

Dial peer 1 would be the inbound dial peer for Site A which has a DID range of 1XXX, and dial peer 2 for Site B with has DID 2XXX. Then, you add a translation profile that for site 1, it adds 1#, site two, adds 2#.

You have two outgoing dial peers:

dial-peer voice 11 voip

destination-pattern 1#9.T

translation pattern (strips off 1#)

dial-peer voice 12 voip

destination-pattern 2#9.T

translation pattern (strips off 2#)

That's tagging. It can be a little easier on the mind to track calls this way.

The other option is corlists, that only allow calls to go out certain outgoing dial peers if they came in certain incoming dial peers. Here's the doc explaining the details/config:

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a008019d649.shtml

hth,

nick

View solution in original post

8 Replies 8

This is possible. What you would do here is use one of two things:

-Intermediary translations (tagging)

-Corlists

Matching an inbound dial peer for the 4 divisions isn't hard. You can have something like this:

dial-peer voice 1 voip

answer-address 1...

translation pattern (to prefix 1#)

dial-peer voice 2 voip

answer address 2...

translation pattern (to prefix 2#)

Dial peer 1 would be the inbound dial peer for Site A which has a DID range of 1XXX, and dial peer 2 for Site B with has DID 2XXX. Then, you add a translation profile that for site 1, it adds 1#, site two, adds 2#.

You have two outgoing dial peers:

dial-peer voice 11 voip

destination-pattern 1#9.T

translation pattern (strips off 1#)

dial-peer voice 12 voip

destination-pattern 2#9.T

translation pattern (strips off 2#)

That's tagging. It can be a little easier on the mind to track calls this way.

The other option is corlists, that only allow calls to go out certain outgoing dial peers if they came in certain incoming dial peers. Here's the doc explaining the details/config:

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a008019d649.shtml

hth,

nick

Nick,

Thank you for getting my creative juices flowing.

The DNs between these multiple organizations are not contiguous which would make it difficult or at least not scalable, to match against an answer range. However I am planning on adding prefix digits to new CUCM route patterns which I would later strip at the gateway utilizing a new or set of new, outbound dial-peers and a new translation pattern while utilizing an existing inbound dial-peer for the initial match. Essentially what you suggested but with the prefix added earlier.

Does this make sense?

Yes that makes sense. Generally, tagging is going to be the more likely scenario because of this exact situation.

But, it's still fun to illustrate that it's possible to contain completely within CUBE. Because if you're a service provider, you may not want to ask customers to send 1# before they send calls to you for whatever reason.

Glad I could help.

-nick

Okay, onto the next issue with this scenario...

Both of the SIP trunks go to the same SIP Domain IP address. So I think, no biggie I will build a policy based routing configuration to identify departments C and D that need to ride this new SIP trunk and set their next hop to the other end of the SIP trunk.

Problem seems to be that call setup and teardown of the H323 from callManager to the SIP trunk will not be matched.

1.) Is there a good link for the call setup and teardown of a h323 to SIP cube call?

2.) Any advice on how to PBR these specific hosts over this second trunk?

Would you mind explaining what problems you have if you don't enable PBR?

I'm not quite sure what is wrong with sending both of the trunks out the same IP routing leg is.

hth,

nick

The problem is/was this. There was a desire to utalize two physical interfaces to segregate load based on departments with the same endpoint IP. Physical link 1 for department A and physical link 2 for department B.

After a TAC case it was determined that the cube translation function happens before the routing of the packets, therefore PBR will never go into effect.

I still appreciate the assitance.

You can probably do this, but it wouldn't be pretty.

How badly do you need to be able to do this?

You could probably use two different session target IP's, and then use a NAT translation to route out different interfaces.

CUBE and PBR are two of my favorite things. What was the SR?

There is also a voice feature that can route on source IP address - voice ip source groups or something of the sort. I've never had to use them but they've been around for a long time.

-nick

Duplicate post.

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: