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

[SourceForge.net]

Bugs item #1827360, was opened at 2007-11-07 09:31
Message generated for change (Comment added) made by miconda
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: 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