[Home]

Summary:ASTERISK-05336: [branch] Support for Diversion: header in redirects of calls with 302
Reporter:Jacob Tinning (tinning)Labels:
Date Opened:2005-10-20 09:30:28Date Closed:2008-01-15 16:28:41.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-chan_sip-1.894_diversion_reason-1.0.patch
( 1) asterisk-chan_sip-8895_diversion_reason-1.1.patch
( 2) asterisk-chan_sip-8895_diversion_reason-1.2.patch
( 3) draft-levy-sip-diversion-07.txt
Description:I need the diversion reason from the parameters in a SIP
Diversion header.

I've written a patch which parse the Diversion parameters and store
the diversion reason in a channel variable, __PRIREDIRECTREASON like
in chan_zap.c.

The reason are "translated" to the reason-strings used in chan_zap.c (and a couple of new ones are added)

This way, it works with modules and dialplans which works with chan_zap.
Comments:By: Olle Johansson (oej) 2005-10-20 09:38:04

If you set the disclaimer to "N/A" we can't look at your file. Do you have a disclaimer with Digium?
By: Jacob Tinning (tinning) 2005-10-20 09:51:38

No, not yet. I will fax a disclaimer to you within a day.
By: Olle Johansson (oej) 2005-10-20 10:04:47

Please confirm as soon as you have sent a disclaimer. Thank you for contributing to Asterisk!
By: Jacob Tinning (tinning) 2005-10-20 10:19:29

A disclaimer should now be in your fax-inbox.


By: Olle Johansson (oej) 2005-10-24 07:52:53

Which RFC documents this?
By: Jacob Tinning (tinning) 2005-10-24 08:12:14

The "Diversion" header is, as far as I know, not documented in any RFC,
including RFC3261. This means that in a SIP compliant implementation, there
is no Diversion header.

I guess I have made a fix to a function, parsing an unofficial header...

However, it is documented in a draft (draft-levy-sip-diversion-07.txt).

I know its not preferable to implement undocumented headers, but if
SIP should ever be used for "real" telephony applications, I think it is
rather important to have a way to pass a diversion address and the reason
for the diversion.


By: Olle Johansson (oej) 2005-10-24 08:51:28

A draft is ok, I just wanted to learn more about it. Thank you! If it's implemented out there, we should propably know about it and look into it. Wonder if we should add the Diversion: header when we send a 302 as well?
How does it work in zap?
By: Jacob Tinning (tinning) 2005-10-24 09:34:01

In chan_zap the redirectreason-value is copied from
the libpri-structure pri_event_ring when a new (incomming)
call is made.

The value is translated to an explaining string, and the channel-variable
"PRIREDIRECTREASON" is set to this string.

I don't think chan_zap sets a redirecting reason when making outgoing calls.

Please give me a day to think about situations in which it would be reasonable to add the Diversion header when making outgoing SIP calls (or responses to
incomming SIP calls.)
By: Olle Johansson (oej) 2005-10-24 10:24:28

Well, app transfer() sends a 302 redirect if the call is not answered. That's where I suppose we could set a Diversion header. As I am striving for multiprotocol solutions, like the one implemented here where you translate the SIP Diversion to a generic status variable, I was curious in how zap handled transfer(), if it does at all.
By: Jacob Tinning (tinning) 2005-10-25 03:28:23

I just looked through chan_zap.c and realized that
tech->transfer is not assigned.

... but `grep -i "transfer" chan_zap.c | wc -l` is 44, and it
looks like something similar to transferring is going on in chan_zap.c

Unfortunately I haven't read *all* of chan_zap.c so I am not 100% shure
how it does call-transfer. Im pretty shure it doesn't pass a
redirectionreason to libpri though.


By: Olle Johansson (oej) 2005-10-25 03:45:48

I'll check with a pri developer...
By: Jacob Tinning (tinning) 2005-10-27 08:50:42

I guess I could add the Diversion header with reason parameter in the
sip_sipredirect() function.

I think the original To address should be copied into the new
Diversion header.
By: Olle Johansson (oej) 2006-01-05 12:08:20.000-0600

Can we get an update that matches current chan_sip and the new strings library?
By: Jacob Tinning (tinning) 2006-01-12 04:53:13.000-0600

Is "current chan_sip" from
svn.digium.com/svn/asterisk/branches/1.2,
svn.digium.com/svn/asterisk/trunk
or asterisk-1.2.1.tar.gz ?
By: Olle Johansson (oej) 2006-01-26 02:33:31.000-0600

Current chan_sip for adding new features is always trunk.

We do not add new features to a released version of Asterisk, in order to minimize the risk of introducing new bugs.
By: Olle Johansson (oej) 2006-01-26 07:56:58.000-0600

Looking at this patch, I am a bit curious on why you set the channel variable in sip_new... Wouldn't it be a bit more logical to set it after you parsed it? I might be missing something important here...
By: Jacob Tinning (tinning) 2006-01-30 07:32:39.000-0600

I've updated the patch to match current chan_sip (svn rev 8895)
and the new strings library.
By: Olle Johansson (oej) 2006-01-30 08:47:48.000-0600

Ok, implemented your patch in the branch "sipdiversion"

http://svn.digium.com/view/asterisk/team/oej/sipdiversion for viewing
http://svn.digium.com/svn/asterisk/team/oej/sipdiversion for checking out

That way, you don't have to keep it up to date with changing trunk.

I still want an answer to my question, though :-)
By: Jacob Tinning (tinning) 2006-01-30 09:08:04.000-0600

I thought it should be set at the same time rdnis were copied to
chan->cid.cid_name - which is only in sip_new.

I agree with you. It should instead be set when it is read.
I could make a
'pbx_builtin_setvar_helper(pvt->owner, "__PRIREDIRECTREASON", i->redircause);'
in get_rdnis instead ?

Im obviously confused about in which order the functions are called..
By: Olle Johansson (oej) 2006-03-29 16:44:20.000-0600

Move the setting of the variable.
By: Eric Osterberg (ejo1) 2006-04-07 17:47:43

OK, I'm trying this out and having the following problem.

svn checkout http://svn.digium.com/svn/asterisk/team/oej/sipdiversion
mv sipdiversion/ asterisk
cd asterisk
make clean
make

#And here's what I get back
chan_sip.c: In function `get_rdnis':
chan_sip.c:6729: warning: suggest parentheses around assignment used as truth value
chan_sip.c:6760: warning: passing arg 1 of `pbx_builtin_setvar_helper' from incompatible pointer type
chan_sip.c:6761: warning: passing arg 1 of `pbx_builtin_setvar_helper' from incompatible pointer type
chan_sip.c: In function `sip_sipredirect':
chan_sip.c:13595: error: syntax error before ')' token
chan_sip.c:13577: warning: unused variable `tmp2'
chan_sip.c:13578: warning: unused variable `reason'
make[1]: *** [chan_sip.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk/channels'
make: *** [subdirs] Error 1

#Earlier I thought I had this complied, but couldn't see anything in the dialplan vars ${SIPREDIRECTREASON} or ${PRIREDIRECTREASON}.

A sip debug does show the following header comming through.
"Diversion: <tel:4029> ;reason=no-answer

Thanks for your help.
By: Olle Johansson (oej) 2006-04-10 07:52:41

It compiles cleanly on my system. Are you sure you have the latest version?
By: Eric Osterberg (ejo1) 2006-04-10 09:36:14

Hi oej,

I had it complied, didn't work, made a few changes, couldn't compile, started from scratch and couldn't get it going from there.  I checked out a clean 1.2 branch copy and all worked well.  In the mean time, I found the SIPGetHeader application and don't need this any longer.
By: Alexander Tull (alex-911) 2006-08-13 06:51:30

hello there

I have just tested the sipdiversion branch. without success, the diversion header is missing in the INVITE that's caused by the 302 response. the diversion header is present in the 302 (from a Cisco 7960 running SIP_8.3).
my setup is the following:
PSTN <-SS7-> CiscoClass4 <-SIP-> B2BUA <-SIP-> AsteriskPBX <-SIP-> IP Phone(s)

the call is incoming from PSTN, the IP phone CFU's back to another PSTN destination.

I have not seen a difference in the sipdiversion branch compared to release 1.2.10... the diversion header is missing...?

I'd really like to help here testing the sipdiversion and I hope it is going to make it into 1.4beta.
the levy draft has expired and the IETF seems not to be willing to make it in an RFC. however, it is used as a de-facto way to send redirecting/diverting information by almost all vendors supporting that type of data so if interoperability is desired .


btw: the latest version of the levy draft is draft-levy-sip-diversion-08.txt

==============================================================================

Connected to Asterisk SVN-oej-sipdiversion-r37267 currently running on unnamedplayer (pid = 5448)
Verbosity is at least 4
.
.
.


<-- SIP read from 192.168.1.23:5060:
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 10.10.1.16:5060;branch=z9hG4bK0c9194f2;rport
From: "0222222222" <sip:0222222222@10.10.1.16>;tag=as6d885210
To: <sip:111111111@192.168.1.23:5060;transport=udp>;tag=003094c3692c03e4413441a7-27fd93e9
Call-ID: 627be6d04a28368134255d6e447d11f1@10.10.1.16
Date: Sat, 12 Aug 2006 17:04:27 GMT
CSeq: 102 INVITE
Server: Cisco-CP7960G/8.0
Contact: <sip:0333333333@sip.labdomain.ch>
Diversion: "alex@home" <sip:111111111@192.168.1.23>;reason=unconditional;privacy=off;screen=yes
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE
Content-Length: 0


--- (12 headers 0 lines)---
Aug 12 19:03:33 DEBUG[5477]: chan_sip.c:1986 __sip_ack: Acked pending invite 102
   -- Got SIP response 302 "Moved Temporarily" back from 192.168.1.23
Transmitting (no NAT) to 192.168.1.23:5060:
ACK sip:111111111@192.168.1.23:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.1.16:5060;branch=z9hG4bK0c9194f2;rport
From: "0222222222" <sip:0222222222@10.10.1.16>;tag=as6d885210
To: <sip:111111111@192.168.1.23:5060;transport=udp>;tag=003094c3692c03e4413441a7-27fd93e9
Contact: <sip:0222222222@10.10.1.16>
Call-ID: 627be6d04a28368134255d6e447d11f1@10.10.1.16
CSeq: 102 ACK
User-Agent: labdomain.ch PBX
Max-Forwards: 70
Content-Length: 0


---
   -- Now forwarding SIP/sip.domain.lab-081e5110 to 'Local/0333333333@privileged' (thanks to SIP/111111111-081e72b8)
   -- Executing [0333333333@privileged:1] Dial("Local/0333333333@privileged-e5b3,2", "SIP/0333333333@10.10.1.10") in new stack
Really destroying SIP dialog '627be6d04a28368134255d6e447d11f1@10.10.1.16' Method: INVITE
Audio is at 10.10.1.16 port 16048
Adding codec 0x8 (alaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x400 (ilbc) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 10.10.1.10:5060:
INVITE sip:0333333333@10.10.1.10 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.16:5060;branch=z9hG4bK4d0ac9c3;rport
From: "0222222222" <sip:0222222222@10.10.1.16>;tag=as7692146a
To: <sip:0333333333@10.10.1.10>
Contact: <sip:0222222222@10.10.1.16>
Call-ID: 61b75e5c3ccde29a670593c924d696ac@10.10.1.16
CSeq: 102 INVITE
User-Agent: labdomain.ch PBX
Max-Forwards: 70
Date: Sat, 12 Aug 2006 17:03:33 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
upported: replaces
Content-Type: application/sdp
Content-Length: 290
.
.
.
By: Olle Johansson (oej) 2006-10-17 14:58:06

Commited to svn trunk rev 45635, Thank you for your work!
By: Olle Johansson (oej) 2006-10-17 15:00:36

Thank you for all the hard work!
By: Digium Subversion (svnbot) 2008-01-15 16:28:41.000-0600

Repository: asterisk
Revision: 8904

_U  team/oej/sipdiversion/
U   team/oej/sipdiversion/channels/chan_sip.c

------------------------------------------------------------------------
r8904 | oej | 2008-01-15 16:28:40 -0600 (Tue, 15 Jan 2008) | 2 lines

Adding patch from issue ASTERISK-5336 created by tinning - support for Diversion: header

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=8904