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

Robert Dyck rob.dyck at telus.net
Wed May 21 18:18:25 CEST 2008 

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 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

More information about the Users mailing list