[OpenSER-Users] Unable to do transformation on expires param if display name present

Tue May 20 22:04:58 CEST 2008

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:246875 at 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 at 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 at lists.openser.org
> > http://lists.openser.org/cgi-bin/mailman/listinfo/users