CUBE Dialpeers "Destination URI" vs "Incoming URI"

[kkhanis]

Hi,

Could someone help me figure out the difference between using "Destination URI" vs the  "Incoming URI" command to match a dialpeer?

Which would take precedence if there are two dialpeers, one with destination uri and other with Incoming URI but they both match the same INVITE?

Thanks,

Kamran

[Jonathan Schulenberg · Accepted solution]

Incoming URI would match as it has superceeded incoming called-number as the most most preferred match criteria.

Destination URI is used for outgoing call leg matching; however, it would be interesting to know if it can work on incoming as a fourth-tier matching criteria (behind URI, incoming called-number, and answer address) as destination-pattern does. The command reference guide doesn't specify and it's not directly related to your question anyways. I'm off on an acedemic tangent now.

Please remember to rate helpful responses and identify helpful or correct answers.

[kkhanis]

Hi Jonathan,

Thanks a lot, the world makes sense now

I tested that but as far as I can see, the destination URI does not work on the incoming dial-peer selection....but ill test more extensively later.

On another note on the same tangent destination uri looks a bit useless to me. Reason:

most deployments I have seen are where the CUBE has address hiding between two separate sip domains. invites from both sides coming with the INVITE header as the CUBE interface. Since its two domains, easiest would have been to match the HOST part of the "TO" field and choose the outbound dial-peer. 2 dialpeers for all outbound connections - simples! not so much:

Inbound uri is powerful enough for us to select the "TO" fieldhost  instead of choose the inbound dial-peer. But the destination uri dial-peer on the other hand can only look at the "INVITE" header which is useless since it will always be the CUBE. IF we have to use the user part of the INVITE header, we might as well use the destination-patter. So we are forced to use the destination pattern or some prefix from CUCM to have simpler dial-peers...

Or is would you know of a better way to do this?

Thanks!

[Jonathan Schulenberg]

It may not be relevent to your config but I wouldn't call it useless. Some customers use CUBE for B2B or other Internet-based calling. An example of this would be CUBE in the DMZ configured to route TO:*@businesspartner.example. There are many different use cases for CUBE beyond PSTN connectivity.

Use incoming URI for inbound dial-peer and destination-pattern for outgoing dial-peer matching.

[kkhanis]

p.s just wanted to update here that routing using destination uri-to matching will be available starting IOS 15.4.1T or IOS-XE 3.11. Exactly what we need!:

p1-CUBE-POD1(config)#dial-peer voice 1 voip

p1-CUBE-POD1(config-dial-peer)#destination ?

  calling           Match destination calling number

  dpg               Configure voice class dpg

  e164-pattern-map  Configure voice class to match destination e164-pattern-map

  provision-policy  Configure voice class dial-peer provision-policy

  route-string      Match destination route-string

  uri               Configure voice class to match destination URI

  uri-diversion     voice class uri to match sip diversion header

  uri-from          voice class uri to match sip from header

  uri-referred-by   voice class uri to match sip referred-by header

  uri-to            voice class uri to match sip to header

  uri-via           voice class uri to match sip via header

p1-CUBE-POD1(config-dial-peer)#destination uri

p1-CUBE-POD1(config-dial-peer)#destination uri-to