|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:38||Date Closed:||2011-06-07 14:03:24|
|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:firstname.lastname@example.org;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:email@example.com;target=bob;cause=486
SIPREQURI() --> sip:firstname.lastname@example.org;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:
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
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.
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
-= Info about function 'SIPCHANINFO' =-
Gets the specified SIP parameter from the current channel
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:email@example.com;target=bob;cause=486
SIPCHANINFO(ruri) --> sip:firstname.lastname@example.org;target=bob;cause=486
SIPCHANINFO(ruri,target) --> bob
SIPCHANINFO(ruri,cause) --> 496
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).
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
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.