Routing based on custom header

[dgonzalez1]

Hello, I'm configuring a Cisco CUBE in which I'm receiving invites with a custom 'Trunk' header that can have different values  like:

Trunk: CH_Barracas_1

The intention is that based on that header, and despite the dialed digits, I can route the call to a specific outgoing dial-peer.

Is that possible?

Thank you.

[b.winter]

Again:
You cannot route based on a custom SIP header!!

That's why I wrote (probably already twice), that this information should be added as a tag in other headers, which the CUBE can route / do the dial-peer selection. E.g. Request-URI header, VIA header, ...
My example was based on the VIA header.

And again:
My example config assumes, that the other system is manipulating the VIA header and adds the tag.
So the original incoming INVITE message already includes the correct VIA header with the additional "Trunk" tag.
But this has to be done on the other system, which is sending this INVITE to the CUBE.
If the other system can add custom SIP headers, it should also be powerful enough to manipulate existing headers.

I don't know how I should describe this more clearer?!

[b.winter]

Why don't you just put the value of your custom header, as an additional parameter / tag in one of the headers, that can be routed by the CUBE?

E.g add ";trunk=CH_Barracas_1" to the request-URI header or VIA header
Looks then like this "Via: SIP/2.0/TCP 1.1.1.1:5060;trunk=CH_Barracas_1"

And then in CUBE you have something like:

voice class uri 200 sip
 pattern trunk=CH.Barracas.1 (You need to use dots here as a wildcard, because CUBE doesn't support to match the underscore)
!
dial-peer voice 200 voip
 incoming uri request 200
 or
 incoming uri via 200

[dgonzalez1]

Ok, I could try that. I was not so sure how the pattern thing worked, but I think is clear now.

To add the trunk to the request-URI I should use sip-profile, right?

[Roger Kallberg]

Yes. See this chapter Copy SIP Headers in the Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards configuration guide.

[b.winter]

Honestly, I personally still don't get, what you are trying to achieve in the first place...

Why do you want to add a header on the incoming dial-peer, just to be used to select the appropriate outgoing dial-peer?
Normally, this custom header / tag is already in the INVITE that hits the CUBE and based on that INVITE, incoming dial-peer selection is done (take the Local GW config for Webex Calling as an example).

Taking your scenario now, you probably will have different "trunk" values.
So you need to think about the incoming dial-peer matching based on numbers or URIs, so that you can later add the "trunk" value (with a sip profile) and then select the outgoing dial-peer based on that header.

But if you have already selected and splitted up the incoming dial-peer selection, you can already set the outgoing dial-peer with dial-peer groups, which renders your concept with a custom header useless.

Edit:
Seeing your INVITE:
Is this the original INVITE that the CUBE receives?

[Roger Kallberg]

Written from memory, so not sure on accuracy. Something like this could work.

voice class sip-copylist 10
 sip-header Via
 sip-header Trunk

voice class sip-profiles 100
 request INVITE sip-header sip Via copy "Via:(.*)" u01
 request INVITE sip-header sip Trunk copy "Trunk:(.*)" u02
request INVITE sip-header Via modify "Via:\u01;\u02"

dial-peer voice 10
 description Inbound Dial Peer
 voice-class sip copy-list 10

dial-peer voice 100 voip
 description Outbound Dial Peer
 voice-class sip profiles 100

[dgonzalez1]

Thanks, but I don't get how if the sip-profile is applied to the outgoing dial-peer it would be selected based on the via header if it has not been modified yet. Shouln't I modify the via header in the incoming one? Am I clear?

Thanks.

[Roger Kallberg]

As your end result is to use different outbound dial peer based on the value of the trunk group you get on the inbound call leg it would not matter if you were to modify the value on the outbound dial peer and use that to match the outbound call leg.

In my last response I forgot to mention that you’ll need to use my suggestion in combination with what @b.winter previously suggested and you’ll need to duplicate what he suggested to match the other values that you get in the Trunk header.

Edit: Your right, I overlooked the fact of the order of operations for when the SIP profile is applied in the outbound direction. With this you’ll need to do this on the inbound call leg.

[Roger Kallberg]

If you absolutely want to do it on the inbound dial peer then just modify my suggestion to have the SIP profile assigned to the inbound dial peer.

[Elliot Dierksen]

If the intent is to use COR in the gateway to force the selection of different outgoing dial peers, I think the matching which would set the incoming COR in the incoming dial peer would need to be done in 'incoming uri'.

[dgonzalez1]

Hello, finally, combining some of your responses, I manage to do make it work usinf the request-uri, not yet using the via header as I wanted:

First, I had to configure a couple of global commands:

voice service voip
sip
call-route url

Second, I configured a sip-profile in the incoming dial-peer:

voice class sip-profiles 901
request INVITE sip-header SIP-Req-URI copy "sip:(.*) SIP/.\.." u01
request INVITE sip-header Trunk copy "Trunk: (.*)" u02
request INVITE sip-header SIP-Req-URI modify "sip:(.*)" "sip:\u01;trunk=\u02 SIP/2.0"

And a voice class uri:

voice class uri 401 sip
  pattern CH.Barracas.1

Finally, added destination uri in outgoing dial-peer:

dial-peer voice 410 voip
description ***Salientes troncal Chile***
session protocol sipv2
session server-group 4
destination uri-via 401
voice-class codec 400
voice-class sip tenant 400
dtmf-relay rtp-nte
no vad

In this way it succeeds to match outgoing dial-peer and send out the invite. What is not very good is that in the sip-profile I had to insert the tag I want between the last existing tag and the SIP version. And, since I can't use more than a variable, I had to readd the SIP version by hard. I didn't find the way to insert the tag and keep the real SIP version I receive.

Also, I tried to do the same manipullating the via header and using the destination uri-via in outgoing dial-peer but in this case the dial-peer is not matched, not sure why. The same using the To header.

If someone knows the possible reason for that, I'll be glad to hear it. And if not, anyway I thing I could leave it like that, although it's not so 'clean' as I would like.

Thank you all.

[Roger Kallberg]

Great job getting it to work. For the good of the community it would be nice if you could post the entire complete configuration of your setup so that others can reference it when needed.

[Roger Kallberg]

Can you not use this as your SIP profile?

voice class sip-profiles 901
request INVITE sip-header SIP-Req-URI copy "sip:(.*) (SIP/.\..)" u01 u03
request INVITE sip-header Trunk copy "Trunk: (.*)" u02
request INVITE sip-header SIP-Req-URI modify "sip:(.*)" "sip:\u01;trunk=\u02 \u03"

[Roger Kallberg]

In your shared configuration you have this under the outbound dial peer, “destination uri-via 401”. Based on your own text I assume that it should be “destination uri 401”.

About your question about why it doesn’t work with the uri-via command. If you were to read the document that I’ve shared with you previously you would see that this command is used in conjunction with Dial-Peer Provision Policy (DPP) and that is defined on the inbound dial peer per this note that I marked from the available outbound dial peer match options.

As such it is not intended to be used in the way that your trying to.

[dgonzalez1]

Ok, sorry Roger, I've been reading a lot and dealing with some other issues and must have miss that.

Regarding the sip-profile, I manage to include the SIP version by modifying the value-t-match in the last line like that:

request INVITE sip-header SIP-Req-URI modify "sip:(.*) SIP/" "sip:\u01;trunk=\u02 SIP/"

Thanks.