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
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Daniel-Constantin Mierla -
Robert Dyck