Subject: [SIP] RE: Lessons Learned

From: Gethin Liddell <[email-masked]>
Date: Thu, 8 Jun 2000 10:41:12 +0100

Jonathan Rosenberg wrote:
>"Adam B. Roach" wrote: 

*snip*

>> 
>> 3) This is actually a disagreement I have with RFC2543, and 
>> one that I raised some time ago; however, no one seemed 
>> interested at the time. Since it actively prevented us from 
>>running one of the test cases we wanted to run at this bakeoff, 
>> I'm going to raise the issue again. Take discussion on this 
>> topic to the SIP working group mailing list, please. 
>> 
>> According to section 6.37, an implementation should reject 
>> messages containing unknown URIs in the "To:" field with 
>> a 400 response. Many implementations actually did this. 
>> The test case we were attempting was as follows: 
>> 
>> UAC1 ----> tel: mapping proxy -----> UAC2 
>> 

*snip*

>> UAC2 definitely has quite enough information to service the 
>> call. In fact, if not for this clause in 2543, the call would 
>> be set up perfectly. I contend that clients shouldn't 
>> care if they understand the URI in the To: field, as long 
>> as they can process the call, and I encourage implementations 
>> to exhibit this behavior. 
>> 
>> This also follows naturally from what I suggested above: don't 
>> validate fields unless you intend to use the information 
>> contained in them. 
>
>Hmm. This is a good point. Given the increasing use of tel URLs, its 
>probably worth changing this in rfc2543bis. This doesn't introduce 
>backwards compatibility problems; it just means that calls to UAs 
>compliant to the bis version will get set up successfully, when they 
>won't with rfc2543. 
>
>In general, the *request URI* is what is important in processing a 
>request. The To field is used only for (1) call leg identification 
>(along with From and Call-ID), and (2) FYI to the called party. The 
>request URI represents the desired user at the server being contacted. 
>The To field may contain a URI which is meaningless within the namespace 
>served by the server. 

I agree with the sentiments here but I have a question.

How is it possible to correctly equate two separate unknown 
URI's in a transaction ID?

For example lets say the server (UA or Proxy etc..) receives a 
To: header that contains an Unknown URI as follows:

To: <newuri:unknown;uri:format?>

A URI allows escaping, may be case sensitive, may be case 
insensitive or may be both. So how is it possible to equate the 
URI above to:

To: <newuri:UNKNOWN;uri:f%4Frmat?>

they may or may not be equal.  it all depends on the URI specification itself.

So if two INVITE's are received, identical apart from the To headers shown above,
what is the server to do.

If it does byte by byte comparison, then it will consider them two separate messages.
If it is really one message then a UA may provide two alertings for the one call or 
may accept one and send a BUSY back on the other.  Whatever, both are wrong.

Conversely, if it unescapes the chars and does a case-insensitive comparison then 
it will consider the two messages identical.  If however, the difference in case is
important to the URI spec then they are in fact two different messages and again the 
action taken will be wrong.

This has been added to the bis draft (Section F, top of page 117, although i can't 
find where it refers to) but it only considers the To header.  This does in fact have
broader implications and is an issue for every element that uses URI's (From, Via,
Request-uri), and subsequently every transaction id, Call-Leg and thus message.

As i see it, the original action (RFC 2543) of sending an error back on Unknown URI's
was the correct one.  It would be nice to handle unknown URI's properly but i don't
see how this is possible.

BTW sorry for bringing up a problem with a thread that is over a month old. Big up the 
massive ;)

-- 
Gethin Liddell
Team Geffin
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 08 Jun 2000 09:53:06 -0400

Gethin Liddell wrote:

> >The To field may contain a URI which is meaningless within the namespace

This was changed April 23 and has been in the 2543bis since that time.

> what is the server to do.

Practically speaking, this would only occur if the other side
intentionally mangled the URL on either responses or for requests in the
other direction. Thus, the correct solution (particularly for URL types
other than SIP) is that the callee copies the URL in the From field into
the To field and vice versa if it wants to send a request in the other
direction (for the same call).

For request-URI, comparison only matters to compute branch ids for
loops. However, request URIs are not likely to be random URI types as
they have to be understood by the receiving proxy. In addition, you'd
have to have a truly strange proxy that does random equivalence
transformations on URLs looked up locally, within the same transaction.

Via's don't contain URLs and obviously have nothing to do with call
legs.

Contact are copied into Request-URIs, so they don't matter for call leg
computation.

Thus, byte-by-byte comparison of unknown URL types would seem to work
fine in practice.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs