[OpenSER-Devel] [ openser-Bugs-1827360 ] transformation evaluation error
SourceForge.net
noreply at sourceforge.net
Thu Nov 8 20:00:39 UTC 2007
Bugs item #1827360, was opened at 2007-11-07 09:31
Message generated for change (Comment added) made by dan_pascu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1827360&group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver devel
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Dan (dan_pascu)
Assigned to: Daniel-Constantin Mierla (miconda)
Summary: transformation evaluation error
Initial Comment:
I have this uri:
$var(x) = "sip:10.0.0.1:5060;origin=\"sip:193.230.183.51:5060;transport=tcp\";socket=udp:1.2.3.4:5060;expire=60";
$(var(x){uri.transport}) evaluates to tcp" (including the end double quote). This is wrong as the transport parameter is part of the inner uri which is quoted inside the origin parameter of the original uri.
However $(var(x){uri.param,transport}) correctly evaluates to an empty string.
Also $(var(x){uri.param,origin}) correctly evaluates to sip:193.230.183.51:5060;transport=tcp
----------------------------------------------------------------------
>Comment By: Dan (dan_pascu)
Date: 2007-11-08 22:00
Message:
Logged In: YES
user_id=1296758
Originator: YES
I think that uri.param should stay. Using 2 transformations to obtain an
uri param will make the script heavier and I don't like it at all.
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-11-08 21:43
Message:
Logged In: YES
user_id=1246013
Originator: NO
It is about the grammar of a uri, if you look in RFC3261, the definition
of uri params do not state quoted values. Relevant lines:
uri-parameters = *( ";" uri-parameter)
uri-parameter = transport-param / user-param / method-param
/ ttl-param / maddr-param / lr-param / other-param
other-param = pname [ "=" pvalue ]
pname = 1*paramchar
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / escaped
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
/ "$" / ","
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
escaped = "%" HEXDIG HEXDIG
As you see, '=' is reserved in uri parameters, as well as ';'.
However, back to root problem. The differences occur because of uri
transformation evaluation.
There are two parsers used in this case. The standard parameters of uri
are parsed by parse_uri function and directly hooked in sip_uri structure.
So, uri.transport
is using it. The uri.param is using a separate parser, that can deal with
any "name=value;..." list, where value can be a quoted string. Same parser
used in "param"
transformation.
In given example, if the uri parameters will respect the grammar, the
results will be the same,
but because you use an unescaped '=' in a supposed value, the results are
different.
Maybe using different parsers, the uri parser for direct hooks of known
standard-specified
parameters, and generic parser for accessing the rest of all is confusing
in this case.
Because is an useful feature, I will keep the uri.param in place, and make
clear in the documentation
this case. Alternative will be to remove the uri.param, and use two
transformations:
{uri.params}{param.name}
----------------------------------------------------------------------
Comment By: Dan (dan_pascu)
Date: 2007-11-07 15:49
Message:
Logged In: YES
user_id=1296758
Originator: YES
That is a posibillity, but is not prefered as it requires extra processing
to unescape. Unescaping is not done automatically and I didn't find any
transformation that would allow me to do it. This is however the only way
to escape such characters in places where quoting using double quotes is
not possible (like for example characters in the username).
However even though I've found no direct reference about quoting parameter
values in the grammar (only about escaping), I found that the rfc
indirectly specifies that a value may be quoted using double quotes for 2
reasons:
1. To enclose a literal that is not evaluated but rather taken as it is
(this allows it to contain reserved characters, like ; in our case)
2. To indicate that a value is case sensitive (otherwise headers, param
names and param values are case insensitive).
Here are the 2 references:
<quote>
A string of text is parsed as a single word if it is quoted using
double-quote marks. In quoted strings, quotation marks (") and backslashes
(\) need to be escaped.
</quote>
<quote>
When comparing header fields, field names are always case-insensitive.
Unless otherwise stated in the definition of a particular header field,
field values, parameter names, and parameter values are case-insensitive.
Tokens are always case-insensitive. Unless specified otherwise, values
expressed as quoted strings are case-sensitive.
</quote>
I also found that user agents use quoting for whatever reason (not obvious
since the values they put in do not need quoting anyway, maybe they do it
for case sensitivity reasons). Here is a contact from a snom320 phone:
Contact:
<sip:dodo at 192.168.0.38:5062;line=8vajryk9>;flow-id=1;q=1.0;+sip.instance="<urn:uuid:24e51374-2fc9-4efe-a88a-319afbbabda4>";audio;mobility="fixed";duplex="full";description="snom320";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-11-07 15:04
Message:
Logged In: YES
user_id=1246013
Originator: NO
... in %hexa (involuntary sending previous comment too early)
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-11-07 15:02
Message:
Logged In: YES
user_id=1246013
Originator: NO
escaping...
----------------------------------------------------------------------
Comment By: Dan (dan_pascu)
Date: 2007-11-07 14:51
Message:
Logged In: YES
user_id=1296758
Originator: YES
Some quoting mechanism must exist for the = and ; characters.
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-11-07 14:33
Message:
Logged In: YES
user_id=1246013
Originator: NO
At first sight, it seems that the SIP grammar do not specify that the uri
parameter value is a quoted string. However, there is an inconsistency in
accessing the standard-defined parameters directly, and accessing them via
the generic parameters list. Some careful reading of the sip rfc is
required here, to understand clear the grammar, and then fix in the right
way.
----------------------------------------------------------------------
Comment By: Dan (dan_pascu)
Date: 2007-11-07 11:34
Message:
Logged In: YES
user_id=1296758
Originator: YES
I guess you were then refering to param.value and param.name
transformations, as there is no s.param transformation.
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-11-07 11:18
Message:
Logged In: YES
user_id=1246013
Originator: NO
I was misled, I was thinking of s.param transformation, rather the "uri"
transformation you are referring. I will double check.
----------------------------------------------------------------------
Comment By: Dan (dan_pascu)
Date: 2007-11-07 10:34
Message:
Logged In: YES
user_id=1296758
Originator: YES
If that is the case, why does it correctly consider the quotes when it
extracts the origin parameter? Plus the issue here is that 2 equivalent
expressions of the same transformation render different results:
$(var(x){uri.transport}) and $(var(x){uri.param,transport}). I think that
if the 2nd one can work correctly, then the 1st one should as well because
in the end is just a more compactly written version of the 2nd.
So the question here is not if they consider quotes (because apparently
they do), but why doesn't one specific transformation {uri.transport} fail
to consider them, while the other more generic transformations
{uri.param,name} do? I suspect other compact forms of uri transformations
that access uri parameters (like uri.ttl, ...) may suffer from this issue
as well.
Regarding the comment that they were meant to only consider a simple list
of ; separated name=value pairs, IMO the uri transformation should consider
the rules for encoding params in an uri, not just a simple list of ;
separated param=value pairs, otherwise they're not very useful for
extracting parameters from an uri if they can't perform their job.
I still consider this to be a bug than a feature request.
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2007-11-07 10:04
Message:
Logged In: YES
user_id=1246013
Originator: NO
The s.param transformation was not intended take in consideration the
quotes. It looks simply just for name1=value1;name2=value2;... If it is
not working now, please add as feature request.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1827360&group_id=139143
More information about the Devel
mailing list