21 May
2008
21 May
'08
7:18 p.m.
To prevent others from falling into the trap, perhaps the documentation about
transformations should warn that the {param.value,name} transformation should
not be used with pseudo-variables because none of the PVs are a pure
parameter list. The script writer must somehow isolate the parameter list (
the s.select ) and then apply the transformation. A single transformation
that accomplished this reliably would be useful.
Thanks for the clarification.
On Wednesday 21 May 2008, Daniel-Constantin Mierla wrote:
On 05/20/08 23:04, Robert Dyck wrote:
Often there is more than one way to achieve the
desired result. In this
case it could probably also be done using textops and some ugly regular
expression. However I still believe I was using the transformation
correctly and that the transformation is broken in some situations.
using the transformation in a rather wrong way and working it is a
corner case. The transformation is based on some core functions that are
used across openser and expects name=value; list for a properly result.
As you say "the
param transformation is designed for 'name=value;' list of tokens". In
this case it is "expires=value" in the example $(ct{param.value,expires}.
Not really, you have a nameaddr there before the params list, with white
space -- probably if you escape the whitespace might work.
When it
works correctly, it locates the parameter list which follows the ";" and
then it searches the parameter list for the named parameter. If $ct
contains white space the parameter list is not found.
By chance is working correctly, taking the first part as a parameter
name. White spaces cannot appear in names, then can appear in values if
the value is enclosed in quotes.
As said, using the s.select transformation before the param
transformation is safest way right now. In the future might be another
transformation that can return the nameaddr part and the parameters
part, but there will be two transformation to be used as well. param
transformation is not going to change as it behaves properly.
Daniel
> The following is an example of the $(ct{param.value,expires} construct
> when it works correctly. Thanks for having a look at this.
>
> May 20 12:58:24 [27654] DBG:core:parse_headers: flags=ffffffffffffffff
> May 20 12:58:24 [27654] DBG:core:parse_param_name: string passed to
> parse_param_name is <sip:246875@192.168.1.3;transport=udp>;expires=0
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is <
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is s
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is i
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is p
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is :
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 2
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 4
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 6
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 8
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 7
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 5
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is @
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 1
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 9
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 2
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is .
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 1
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 6
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 8
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is .
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 1
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is .
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is 3
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is ;
> May 20 12:58:24 [27654] DBG:core:parse_param_name: string passed to
> parse_param_name is transport=udp>;expires=0
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is t
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is r
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is a
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is n
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is s
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is p
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is o
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is r
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is t
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is =
> May 20 12:58:24 [27654] DBG:core:parse_param_name: string passed to
> parse_param_name is expires=0
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is e
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is x
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is p
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is i
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is r
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is e
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is s
> May 20 12:58:24 [27654] DBG:core:parse_param_name: next char is =
> May 20 12:58:25 [27654] DBG:core:run_transformations: return val is 0
> May 20 12:58:25 [27654] DBG:core:comp_scriptvar: str 20 : 0
> looks like deregistration
>
> On Tuesday 20 May 2008, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> the param transformation is designed for 'name=value;' list of tokens.
>> To fix your case you should use s.select transformation, options are:
>> - take the token after the last white space and then apply param
>> transformation
>> - take the token after the last '>', then apply param transformation
>>
>> Cheers,
>> Daniel
>>
>> On 05/20/08 08:41, Robert Dyck wrote:
>>> I am currently using 1.3.2 but this problem exists in older versions as
>>> well.
>>>
>>> My config script includes a transformation on the expires parameter in
>>> a Contact header. I have found that a Linksys SPA3000 will include the
>>> display name in the Contact header and that there is white space
>>> between the display name and the URI. The function parse_param_name in
>>> parse_param.c will stop parsing when it encounters the white space.
>>>
>>> As a workaround I commented the line in parse_param_name that checks
>>> for white space. This works for me but I do not know if there are side
>>> effects.
>>>
>>> This form of Contact is not common but it appears to be legal according
>>> to RFC 3261.
>>> 20.10 Contact
>>> A Contact header field value provides a URI whose meaning depends on
>>> the type of request or response it is in.
>>> A Contact header field value can contain a display name, a URI with
>>> URI parameters, and header parameters.
>>> This document defines the Contact parameters "q" and
"expires". These
>>> parameters are only used when the Contact is present in a REGISTER
>>> request or response, or in a 3xx response. Additional parameters may be
>>> defined in other specifications.
>>> When the header field value contains a display name, the URI including
>>> all URI parameters is enclosed in "<" and ">". If
no "<" and ">" are
>>> present, all parameters after the URI are header parameters, not URI
>>> parameters. The display name can be tokens, or a quoted string, if a
>>> larger character set is desired.
>>> Even if the "display-name" is empty, the "name-addr"
form MUST be used
>>> if the "addr-spec" contains a comma, semicolon, or question mark.
There
>>> may or may not be LWS between the display-name and the "<".
>>>
>>> Here is an excerpt from my script --
>>> if ((is_present_hf("Expires") &&
$(hdr(Expires)
>>> {s.int}) == 0)\
>>>
>>> ||($(ct{param.value,expires}) == '0'))
>>>
>>> {
>>> log(1, "looks like
deregistration\n");
>>>
>>> I added some debug messages to illustrate the problem --
>>>
>>> May 19 22:16:32 [14447] DBG:core:parse_param_name: string passed to
>>> parse_param_name is RJD
<sip:17476316719@192.168.1.4:5061>;expires=3600
>>> May 19 22:16:32 [14447] DBG:core:parse_param_name: next char is R
>>> May 19 22:16:32 [14447] DBG:core:parse_param_name: next char is J
>>> May 19 22:16:32 [14447] DBG:core:parse_param_name: next char is D
>>> May 19 22:16:32 [14447] DBG:core:parse_param_name: next char is
>>> May 19 22:16:32 [14447] ERROR:core:parse_params: invalid character, ;
>>> expected May 19 22:16:32 [14447] DBG:core:run_transformations: return
>>> val is -1 May 19 22:16:32 [14447] CRITICAL:core:comp_scriptvar: cannot
>>> get left var value
>>> May 19 22:16:32 [14447] WARNING:core:do_action: error in expression
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users