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. 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}. 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.
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:[EMAIL PROTECTED];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:[EMAIL PROTECTED]: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
> > [email protected]
> > http://lists.openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.openser.org/cgi-bin/mailman/listinfo/users
