CUBE to handle two Diversion Headers with SIP-Profile

[yellomello]

Hello everyone, 

Scenario is as follows:

ITSP > CUBE > CUCM > Phone A call forward to Phone B > Phone B call forward to Mobile > CUCM > CUBE > ITSP

Within the above scenario, CUCM is sending two Diversion Headers within the INVITE sending to CUBE. 

Received:
INVITE sip:destinationnumber@address:5060 SIP/2.0
Diversion: "Phone 3" <sip:numberphoneB@ip-address>;reason=unconditional;privacy=off;screen=yes
Diversion: "Phone 2" <sip:numberphoneA@ip-address>;reason=unconditional;privacy=off;screen=yes
P-Preferred-Identity: <sip:number-of-initial-caller@ip-address>

Here are the important parts of the configuration:

voice class sip-copylist 1000
sip-header P-Preferred-Identity
sip-header Diversion
!
dial-peer voice 1001 voip
description ### From CUCM ###
voice-class sip copy-list 1000
!

voice class sip-profiles 2051
rule 1 request INVITE peer-header sip P-Preferred-Identity copy "sip:(.*)@" u01
rule 2 request INVITE peer-header sip Diversion copy "sip:(.*)@" u01
rule 3 request INVITE sip-header P-Preferred-Identity modify "<sip:.*@(.*)>" "<sip:\u01@provider.com>"
!
dial-peer voice 2051 voip
description ### To Service Provider ###
voice-class sip profiles 2051
!

The SIP-Profile is working fine when there is one Diversion Header but it fails with two Diversion headers, because then CUBE is doing the following with the Outbound INVITE to ITSP.

Sent:
INVITE sip:destination-number@provider.com:5060 SIP/2.0
P-Preferred-Identity: <sip:numberPhoneB@ip-address>;reason=unconditional;privacy=off;screen=yes,"Phone 2" <sip:numberphoneA@provider.com>

And of course, Provider is not able to handle it and declines the call.

Any idea why CUCM is sending the two Diversion Headers, how I can avoid it or how CUBE can handle the two diversion headers with the given SIP-Profile?

Many Thanks in advance
Michael

[Roger Kallberg]

Maybe not strictly related to your question on two Diversion headers, but you cannot use the same variable in your SIP profile for the two copy statements.

voice class sip-profiles 2051
rule 1 request INVITE peer-header sip P-Preferred-Identity copy "sip:(.*)@" u01
rule 2 request INVITE peer-header sip Diversion copy "sip:(.*)@" u01
rule 3 request INVITE sip-header P-Preferred-Identity modify "<sip:.*@(.*)>" "<sip:\u01@provider.com>"

Try with this instead

voice class sip-profiles 2051
rule 1 request INVITE sip-header P-Preferred-Identity copy "sip:(.*)@" u01
rule 2 request INVITE peer-header sip Diversion copy "sip:(.*)@" u02
rule 3 request INVITE sip-header P-Preferred-Identity modify "<sip:.*@(.*)>" "<sip:\u01@provider.com>"

According to the SIP profile tester that now lives again at this link https://cway.cisco.com/csa-new/#/sipprofiletest it seem to take the copied value from the Preferred Identity in rule 1 and use it in rule 3.

[b.winter]

Hi Michael,
I doubt, that CUCM is adding the second Diversion Header. Most likely, the SIP message is already coming into CUCM from outside with 2 headers. Most of the times I had this "problem", and incoming call from the SIP provider already contained a Div-Header, because Provider don't "clean" up there messages ("None of their businesses" they tell me a lot).

So maybe check for such calls, where they originated and then "clean up" your message already at the first entry point.
E.g. you could add an incoming sip profile to delete the Div-Header, when the call is coming in from the PSTN. It will delete the header if own is there, and if no header is there, it just does nothing.

@Roger Kallberg:
Yes, you can use the same variable as temporary storage. It just gets overwritten.

[Roger Kallberg]

@b.winter  Obviously you can do that, but what’s the point of doing that as you would only be able to use the value of the last copy statement?

[b.winter]

It's more or less a standard "pattern" with those 3 rules here in Germany, to fill the PAI or PPI with a number, which belongs to the SIP-trunk number range, to "authenticate" the calls (normal outgoing and forward to external calls).

If the it's an outgoing call, rule 2 cannot match and you will copy the PAI/PPI from the incoming message (from CUCM) to the outgoing message (to PSTN).

If it's a forwarded call which comes from external, the PAI / PPI will be the external number and so, the call would fail.
Therefore, you overwrite the PAI / PPI with the diversion header number (which can only be an internal number)

[yellomello]

Hi Roger, 

thank you for the input.

The copy statements are there for a specific reason. If there is no Diversion Header present in the INVITE, then the PPI will be used that will be sent by Call Manager because it is a valid PPI as the call initiated by a company own phone, so the landline number is correct and matches the ITSP provided number. But if there is a Diversion Header present in the INVITE, then the PPI will be overriden with the Diversion Headers Value, because the PPI sent by CUCM is the number of the initial caller (in this case from external). 

This is actually a very valid configuration scenario and of course verified by a lot customer environments.

The Problem here is really the two Diversion Headers by CUCM, which are causing this problem. If there is one Diversion Header, everything is working as expected but not with two Diversion Headers. 

The SIP-Profile rule should stop at the first @ sign but it goes all the way through the second @ sign in the second Diversion Header and causing the issue. I already tried to add the IP-Address as well (to have a better match) but that doesn't help because it's the same for both.

[Roger Kallberg]

@yellomello  Thanks for clarifying your use case, makes sense.

[yellomello]

For now I found a workaround for the moment, which could match the customer specific use-case but it could have issues.

I changed rule 2 to this one:
rule 2 request INVITE peer-header sip Diversion copy "<sip:(\+...............)@" u01

I've got this from this post here:
SIP-Profile copy with two @ in the History-Info Header - Cisco Community

The static match based on the number works for now but it's definitely not a dynamic solution.