SIP Diversion Header

[Shortcode]

Is anyone else having problems with SIP Diversion Headers. I have set it in the SIP line information. However neither the carrier nor I see the message in our traces. I have unchecked the box in the twinning under system. I have set the drop down box in the SIP line. Am I missing something?
Thanks.

 

[eddiebullman]

I Have this working with voiceflex sip trunks what I had to do to fix the problem is only register only one account with them
It will not work if you register multiple accounts from the same IP address

the cli is pass through on diverted call

 

[Shortcode]

I am only using one account to register. One thing that is odd is when I view my trunk in system status I see 12 lines, when I only have licensing etc. for 4. I am also sending the calling information via the ARS table.

"If you do things right, people won't be sure you've done anything at all."

 

[IPOfficeIreland]

Yes, disable Send Original Caller ID in System.

If you set the SIP trunk to use Diversion Header you see that it only populates the header with ALIAS (also called DISPLAY Name) & SIP_Name (also called Local_URI) depending on whether you set it to use the trunk of user SIP settings, not the desired Twinned Number, which you would expect?



INVITE sip:twinned_number@SIP_Server SIP/2.0
Via: SIP/2.0/UDP myPublicIP:48387;rport;branch=z9hG4bKe597e80815060d00094a8155f045fed4
From: <siputside_callers_number@myPublicIP>;tag=31df907e55cdb017
To: <sip:twinned_number@SIP_Server>
Call-ID: 93aede3fc775551cc7d19361adcf6f8e@myPublicIP
CSeq: 1763067420 INVITE
Contact: "ALIAS" <sip:Contact@myPublicIP:48387;transport=udp>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Content-Type: application/sdp
Supported: timer
Diversion: "ALIAS" <sip:SIP_Name@myPublicIP:48387>;reason=unknown
Content-Length: 301

v=0
o=UserA 3608107052 3576923007 IN IP4 myPublicIP
s=Session SDP
c=IN IP4 myPublicIP
t=0 0
m=audio 59711 RTP/AVP 8 18 0 4 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


If you set the SIP Trunk to use Remote Party ID you notice this line instead of Diversion Header:

Remote-Party-Id:<siputside_callers_number@myPublicIP:48387>;screen=yes


However, the "From" Field gets updated with the proper outside caller's ID if you use either method.

So, in summary, ask your provider to either look at the FROM field or Remote Party ID in the header for the desired caller id. But you have to set Remote Party ID in the trunk for the From field to be updated also.

Don't bother with Diversion.

Have been trying forwarding using SS but doesn't work.

 

[kholladay]

I don't 100% agree with the statement about "Don't bother with Diversion". If you think about it, diversion is really the most proper way to handle a forwarded call as it includes all of the appropriate information including the true To, From, Diversion/Redirection and if setup properly reason for diversion.

Kyle Holladay
ACA-I, ACA Call Center, ACS-I, ACS-M,
ACE Implement: IP Office
TIA-CTP, MCP/MCTS Exchange 2007
Adtran ATSA, Aruba ACMA

"Thinking is the hardest work there is, which is the probable reason why so few engage in it." - Henry Ford

 

[Shortcode]

I agree. As I am in a test lab for a provider trying to gain IP Office acceptance on their product. This is still a problem for me. I do not see a diversion header at all. It is not as if it is incorrect. It is just non-existant. What causes this to fail? There must be a setting conflict somewhere, I just cannot pinpoint where it is.

"If you do things right, people won't be sure you've done anything at all."

 

[IPOfficeIreland]

I would use Diversion header if it contained the correct info, if it does not, they why bother? do you want to see the outside caller original id or not.

 

[Shortcode]

The provider just wants to see the header and determine if their equipment can offer the feature on the IP Office. Without an example header we have no way of knowing if it is a correct message for their servers. I just need to see it.

"If you do things right, people won't be sure you've done anything at all."

 

[IPOfficeIreland]

just tell them to take the caller id from the FROM HEADER and follow my instructions, it will work every time.

 

[Shortcode]

Well that is a round-about way of achieving. However like I mentioned before, we are testing this in a provider lab (a large provider), and we need the diversion to either work, or not work. After hours of adjusting and rebuilding my SIP trunks and call routes I have determined that it is not working in the manner described in the 'manual', especially with the minimum detail offered on the feature. There are no aids, or anything online for this. Tough cookies, no diversion for now.

"If you do things right, people won't be sure you've done anything at all."