Removing Diversion header on inbound SIP call into CUBE

[Erick Bergquist]

Hi,

Having issues with an inbound call from a SIP provider, where the original call is going to number at other organization which is forwarded to one of our numbers. If we call our number directly it works fine.  

The only difference between the working call and problem call is in the inbound SIP INVITE message, the forwarded call from the other organization system has a Diversion header. 

From my initial research, the format of the Diversion header appears to be correct. 

IOS version 15.3(2)T3 on 2900 series.

SIP DEBUG:

015612: May 23 2014 22:17:31.738 CDT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
INVITE sip:5551234567@10.10.10.10:5060;dtg=tg1trwr SIP/2.0
Via: SIP/2.0/UDP 192.168.10.2:5060;branch=z9hG4bKo4tg142088m1q7qtl731.1
From: <sip:5553331234@192.168.10.2;user=phone>;tag=SDpkp1e01-181400435-1400901451719-
To: "5551234567 5551234567"<sip:5551234567@192.168.10.10>
Call-ID: SDpkp1e01-67b70de54afc625473260a5bdbaa4063-v300g00
CSeq: 371056612 INVITE
Contact: <sip:5553331234@192.168.10.2:5060;transport=udp>
Diversion: <sip:192.168.10.2:5060;user=phone>;reason=unconditional;counter=1
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Accept: application/media_control+xml,application/sdp,multipart/mixed
Max-Forwards: 68
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 286

v=0
o=BroadWorks 68229083 1 IN IP4 192.168.10.10
s=-
c=IN IP4 192.168.10.10
t=0 0
m=audio 59874 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

015613: May 23 2014 22:17:31.742 CDT: //1075181/C70DCE678FDB/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 400 Bad Request - 'Malformed CC-Diversion/Diversion/CC-Redirect Header'

It looks like you need to be IOS 15.4T to use a SIP profile on a inbound call.  I was thinking of using one to remove the Diversion header inbound but not sure if it will work since it is malformed, Maybe the CUBE will reject call before processing the SIP profile. 

I looked for bugs regarding Diversion header in 15.3(2)T3 and didn't find anything yet.

Has anyone worked on a issue like this before or has further ideas?

I have been working with the other organization and providers for a few days now to try to correct it on their end, but was also trying to get the call to be accepted on our side. 

[Manish Prasad]

SIP profile will not work in this case, its only works for outbound direction.

You can try two options , first add the IP address of diversion header (i.e. 192.168.10.2) in IP trusted list if that didn't work then try by using pass-thru command.

[Jorge Armijo]

Kudos to Manish, 

Indeed the SIP Profiles work for outgoing direction only, in additon to permit the Diversion Header will force the CUBE to pass all the unsupported headers as stated on the command reference, you may consider tha fact that the device behind the CUBE also allows inbound DIVERSION.

voice service voip

sip

pass-thru {content {sdp | unsupp} | headers {unsupp | list tag}}

~jorge

[Erick Bergquist]

In 15.4T IOS they added support to use SIP Profiles on inbound calls... I'm not on 15.4T yet so was seeing if someone has done this or seen this problem. 

Does anyone see problem with the Diversion header format in red above?

From reading the RFCs and other SIP documentation, the header seems to be formatted in an acceptable format.

Diversion: <sip:192.168.10.2:5060;user=phone>;reason=unconditional;counter=1

The pass-thru list did not work, as I believe IOS is rejecting the call due to problem header before it gets to the pass-thru or SIP Profile point of the process. 

Had same result, same SIP debug above with pass thru list...

voice class sip-hdr-passthrulist 101
 passthru-hdr Diversion

dial-peer voice 1001 voip
 description Test header issue
 session protocol sipv2
 session target ipv4:x.x.x.x
 incoming called-number 5553331234
 voice-class codec 1
 voice-class sip pass-thru headers 101

[Suresh Subramanian]

Hello Erick,

could you please try the below inbound sip profile configurations and let us know how it works?

>> Steps to enable SIP profile for Inbound direction

1.    enable

2.    configure terminal

3.    voice service voip

4.    sip

5.    sip-profiles inbound

>> create the SIP Profiles to remove the diversion hearder

voice class sip-profiles 1

response ANY sip-header Diversion remove

request ANY sip-header Diversion remove

Apply the SIP Profile to the inbound dial-peer

dial-peer voice XXX

**XXX is the Inbound dial peer number to where we're removing the diversion header**

voice-class sip profiles 1 inbound << applying the inbound sip profile>>

>> Please check if this works. If not, please collect the debug voice ccapi inout & debug ccsip message

//Suresh

Please rate all the helpful posts

[Suresh Subramanian]

Hi Erick, sorry, as you said, the inbound sip profile feature is introduced on 15.4(2)T and overlooked the version 15.3(2)T3 you have.

[Manish Prasad]

I think the diversion header is not in correct format , it should contain the number from which it was diverted.

Diversion: <sip:xxxxxx@192.168.10.2:5060;user=phone>;reason=unconditional;counter=1.

Do a testing on internal extension , set one of the internal extension diversion to an external number which goes through this CUBE , now call the internal number from an extension and check the diversion header in the INVITE message sent by CUCM to CUBE.

Look at the diversion header and check how CUBE respond to that INVITE. You might get your answer.

[maharris]

Just posting for posterity, since this is old conversations, but we ran into this, it was a problem with a 'triggered invite' (designated by that counter=1 in the diversion header).  We were able to get past it by configuring EITHER of these commands under voice service voip, sip:

no supplementary-service sip moved-temporarily

OR

no pass-thru contend SDP

Mary Beth