CUCM drops/removes Diversion header that it received from CUBE

[irusev@intracol.com]

Hi All ,

My setup is :   SIP Provider <--SIP--> CUBE <--SIP--> CUCM  <--SIP-->  Phone

CUCM Version 11.5

In this setup the CUBE receive an Invite from the SIP provider with a Diversion header in it.

Then CUBE sends the Invite to CUCM  and the Diversion header is still there . So CUBE seems to working OK and passing along the Diversion header it received . 

Then when CUCM Sends the Invite to the Phone the DIversion header is missing ??

Here is how the header looks when entering the CUCM :

Diversion: < sip:001333333333@XX.XX.XX.XX> ;reason=unknown

The SIP Trunk connecting to CUBE has the option checked :

Redirecting Diversion Header Delivery - Inbound

And with the same setup a call coming from another Provider using the same SIP trunk between CUBE and CUCM seems to work fine. The Diversion header is passed on to the Phone fine.

Could it be because of the field:  reason=unknown  ? That seems to be the only difference that I see ...

Regards,

ivo

[Abhay Singh Reyal]

As per the call flow my understanding is that you are calling to a SIP Phone. Did you try calling a SCCP Phones and faced the same issue ?
Can you collect the debug ccsip messages and CUCM traces for a working and non working scenario ?
Provide the below details
Calling Number
Called Number
Time stamp
Also make sure to collect the debugs and traces of the same call.

Regards
Abhay

[irusev@intracol.com]

Hi ,

Here is teh SDL log with 2 examples .

Frirst we get a call from the SIP provider :

00890439.002 |16:29:35.872 |AppInfo  |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 1459 from 10.191.40.200:[51997]:
[25721,NET]
INVITE sip:6001@10.191.40.10:5060 SIP/2.0

...

And then a second call comming from another CUCM server via CUBE :

00890906.002 |16:31:44.089 |AppInfo  |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 1421 from 10.191.40.200:[51997]:
[25751,NET]
INVITE sip:6001@10.191.40.10:5060 SIP/2.0

.....

Regards

Ivo

[irusev@intracol.com]

Hi guys ,

Has anyone seen CUCM behave in that way ? And what could be causing it ?

The key is that the Diversion happens outside the CUCM cluster  and when CUCM receives the SIP Invite  with the Diversion header:

-   in one cese it passes it to the Internal Phone  fine and then

 -  in the other case  it removes it  and the phone doe snot have clue who forwarded the call.

In both cases I am hiting the same internal DN (meaning the external user has forwarded his phone to a DID that point to the same Internal Nuber . )

In boteh cases the call comes in via the same SIP trunk  between Cube and CUCM ...

I really need some help in understanding this strange behaviour.

Regards,

Ivo

[irusev@intracol.com]

Hi All ,

Any Help will be really appretiated .... Anyone ?

Regards

ivo

[Ayodeji Okanlawon]

One suggestion you could try is create a sip profile that will modify  the diversion header to look like that or a working one before sending it to cucm. If you need help with let me know. 

[irusev@intracol.com]

OK I will try that and Yes if you have a resource or a hint Handy on  how to do that in CUBE that would be great . Or should I be beter /easier  do it in CUCM ?

But I wanted to understand what is that CUCM does not like about the ITSP DIversion header .  Maybe I can persuade them to change it on their side .

Regards

ivo

[Ayodeji Okanlawon]

Okay I will write a sip profile for you. If you want to do it  your self then its easier to do it on the cube. 

I will need to check some of my logs to see what a diversion header should look like and do some research on why cucm doesn't like this. 

May I ask what issue this is causing. 

[irusev@intracol.com]

The goal is to show the number of the person who forwarded the call to the DID .

UserA  122222222

UserB  133333333

DID    : 144444444

UserB forwards his phone to the DID . And userA calls userB .

As a result our internal Phone rings  and shows    UserA number which is OK but we need it to show  also who Forwarded the call to the DID so we need to see also UserB number .

And that seems to wrork fine if we  manage to pass along  the Diversion header to the  internal Phone .

See the CUCM Log file attached to my second post  for an example as CUCM receives it.

Regards,

ivo

[irusev@intracol.com]

It really seems that CUCM cannot handle a Diversion header with "reason=unknown" and drops it .

To work around this one can do a SIP Normalization at the Border element and rewrite the Diversion header  to have a more "likeable" reason for CUCM :

voice class sip-profiles 1
 request INVITE sip-header Diversion modify ";reason=unknown" ";reason=unconditional"

Hopefully this is helpfull for someone in the future  .