[OpenSER-Devel] [ openser-Bugs-1827360 ] transformation evaluation error

SourceForge.net noreply at sourceforge.net
Wed Nov 7 13:49:03 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-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