[Home]

Summary:ASTERISK-07567: [patch][post 1.4] add Request-URI (RURI) handling to SIPCHANINFO() function
Reporter:Christian Schlatter (cschlatt)Labels:
Date Opened:2006-08-20 21:43:38Date Closed:2011-06-07 14:03:24
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.patch.2
( 1) chan_sip.patch.3
Description:I did not find a way to get access to the Request-URI string of an incoming SIP request from the dialplan. This is needed to support R-URIs that include URI parameters like e.g. sip:voicemail@sip.com;target=bob;cause=486 (the new RFC 4458 defines URIs like this for voicemail/UM usage).

This patch adds a new sip channel variable named SIPRURI that includes the full Request-URIs. Additionally, a new function called SIP_RURI_PARAM(param_name) gives direct access to R-URIs parameters. Using the example R-URI from above, the function call SIP_RURI_PARAM(target) would return "bob", and SIP_RURI_PARAM(cause) "486".

This new function allowed me to implement an RFC 4458 compliant voicemail server with Asterisk.
Comments:By: Tilghman Lesher (tilghman) 2006-08-20 23:21:39

I would ditch the separate channel variable and simplify the function name to SIPREQURI(<param>).  If you really need the full header, use a special keyword like SIPREQURI(full).

We're really trying to get away from setting variables on channels needlessly; using a dialplan function makes this something that doesn't need to be instantiated as a channel variable, and maintains the protection of readonly variables at the same time.
By: Christian Schlatter (cschlatt) 2006-08-21 10:11:50

Ok, that makes sense to me. I've attached a new patch (chan_sip.patch.2) against svn revision 40773.

The function name is now SIPREQURI and an empty argument returns the full R-URI.

Example R-URI: sip:voicemail@sip.com;target=bob;cause=486

SIPREQURI()       --> sip:voicemail@sip.com;target=bob;cause=486
SIPREQURI(target) --> bob
SIPREQURI(cause)  --> 496
By: Christian Schlatter (cschlatt) 2006-08-23 10:53:56

I just found out that there is a whole bunch of SIP URI parameters defined by several SIP RFCs:

(from http://www.iana.org/assignments/sip-parameters)

Parameter Name     Predefined Values     Reference
--------------     -----------------     ---------
cause              Yes                   [RFC-jennings-sip-voicemail-uri-06.txt]
comp               Yes                   [RFC3486]
content-type       No                    [RFC4240]
delay              No                    [RFC4240]
duration           No                    [RFC4240]
locale             No                    [RFC4240]                
lr                 No                    [RFC3261]
maddr              No                    [RFC3261]
method             Yes                   [RFC3261]
param[n]           No                    [RFC4240]
play               No                    [RFC4240]
repeat             No                    [RFC4240]
target             No                    [RFC-jennings-sip-voicemail-uri-06.txt]
transport          Yes                   [RFC3261]
ttl                No                    [RFC3261]
user               Yes                   [RFC3261]
voicexml           No                    [RFC4240]

As an example, according to RFC 4240, a SIP URI like

sip:annc@ms2.example.net;play=http://audio.example.net/allcircuitsbusy.g711

can be used to specify what sound file gets played on the media server.

So having access to R-URI parameters through a dialplan function surely makes sense. I've faxed my disclaimer letter today.

Christian
By: Olle Johansson (oej) 2006-08-30 10:15:13

I don't think this should be a separate function. It should be part of the SIPCHANINFO function that reveals information about the incoming INVITE. Adding yet another function confuses things.
By: Christian Schlatter (cschlatt) 2006-08-31 09:56:55

I've added a new patch (chan_sip.patch.3, against revision 41573) that implements the following:

sip2*CLI> show function SIPCHANINFO
sip2*CLI>
 -= Info about function 'SIPCHANINFO' =-

[Syntax]
SIPCHANINFO(<item>[,<param>])

[Synopsis]
Gets the specified SIP parameter from the current channel

[Description]
Valid items are:
- peerip                The IP address of the peer.
- recvip                The source IP address of the peer.
- from                  The URI from the From: header.
- uri                   The URI from the Contact: header.
- ruri[,param]          The Request-URI from the SIP request, <param> specifies SIP URI parameter value.
- useragent             The useragent.
- peername              The name of the peer.
- t38passthrough        1 if T38 is offered or enabled in this channel, otherwise 0


Example R-URI: sip:voicemail@sip.com;target=bob;cause=486

SIPCHANINFO(ruri) --> sip:voicemail@sip.com;target=bob;cause=486
SIPCHANINFO(ruri,target) --> bob
SIPCHANINFO(ruri,cause) --> 496

-Christian


By: Serge Vecher (serge-v) 2006-08-31 10:17:43

cschlatt: thanks for updating the patch quickly. Can you please fax the disclaimer in to digium (see bottom of http://bugs.digium.com/main_page.php) and make a note here when you do that?
By: Christian Schlatter (cschlatt) 2006-08-31 10:21:37

I faxed the disclaimer on 08-23-06 (my full name is Christian Schlatter).

thanks
By: jmls (jmls) 2006-11-01 06:30:24.000-0600

can we confirm that the disclaimer was received ? Thanks
By: Olle Johansson (oej) 2006-11-07 02:18:05.000-0600

The request URI is divided into two parts, the extension and the SIPDOMAIN. For outbound calls, we read the SIP_URI_OPTIONS parameter. Maybe we should simply set that parameter for SIP options or add just the URI options to the dialplan function, since the rest of the URI is reachable?
By: Olle Johansson (oej) 2006-11-30 15:01:00.000-0600

Any comments?
By: Christian Schlatter (cschlatt) 2006-11-30 21:36:23.000-0600

I think it's nice to have direct access to r-uri option values like with e.g. SIPCHANINFO(ruri,target). Otherwise one would have to parse the full r-uri option string in the dialplan. Having direct access could also be achieved by adding a parameter to the SIP_URI_OPTIONS variable, something like SIP_URI_OPTIONS(<option_name>). On the other hand that would be rather confusing since writing an r-uri option would use a different syntax than reading it.

I don't know what you mean with "add just the URI options to the dialplan function".

Considering all that, I still think that SIPCHANINFO(<item>[,<param>]) represents a logical and easy to use solution. What would speak against it?
By: Olle Johansson (oej) 2007-01-08 10:02:22.000-0600

If we can avoid saving more information per call in the pvt, I would appreciate that. The only thing missing in the dialplan is the options, not the r-uri in itself. I'll check and see what I can propose.
By: Olle Johansson (oej) 2007-02-15 15:31:19.000-0600

I still don't like saving all of the URI in memory, duplicating information we already have. Can we do this in a different way than adding more data to the sip_pvt
By: Olle Johansson (oej) 2007-05-16 06:03:55

No answer from reporter. Will re-open when we have more information, or updated code.

Cheers,
/O