Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus)

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 23 Nov 2000 19:52:28 -0800

Hi Jonathan,
> 
> Since we don't dictate routing behavior, so too would the 
> format of these
> URLs not be specified. So, if we assume the caller is 
> [email-masked], and
> the called party is [email-masked], one choice for the URL 
> pair (request,
> response) is:

So you are saying that the Record-Route SHOULD at least contain the
user@host portions of the Contact or Request-URI in some form or another. We
should _suggest_  a method for acheiving this. For SIP URL's, I think the
first method (below) is the best for sustaining your protocol invariant
property. 
> 
> ([email-masked];maddr=proxy, [email-masked];maddr=proxy)
>
The second method (inserting an escaped URL) is probably best recommended
when you are forced to construct a Record-ROute header from a non-SIP URL
(for generality).
> 
> ([email-masked], 
> [email-masked])
> 
Don't you mean 

(sip%3aA%64originating.com@proxy, sip%3aB%64server12.terminating.com@proxy)
?? 

If not, why not ? 

[I added the "sip:" to a) better identify the escaped URL (rather than just
relying on the "@") and  b) to differeniate non-SIP URL's which may not have
a "@" eg (tel%3a555-1234@proxy)]

Is it worthwhile suggesting different methods for SIP and non-SIP URL's ? Or
KISS and just stick with the latter, more general method?

Cheers,

Robert.

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 24 Nov 2000 10:30:58 -0000

Robert Fairlie-Cuninghame wrote:
>
> Jonathan Rosenberg wrote:
>
> > format of these URLs not be specified. So, if we assume the
> > caller is [email-masked], and the called party is
> > [email-masked], one choice for the URL pair (request,
> > response) is:
> 
> user@host portions of the Contact or Request-URI in some form or 
> another. We should _suggest_  a method for acheiving this. For
> SIP URL's, I think the first method (below) is the best for
> sustaining your protocol invariant property. 
> > 

It works as long as the Request-URI doesn't already have an
maddr parameter. &:)

> (sip%3aA%64originating.com@proxy, 
> sip%3aB%64server12.terminating.com@proxy)
> ?? 
> 
> If not, why not ? 
> 
> [I added the "sip:" to a) better identify the escaped URL (rather 
> than just relying on the "@") and  b) to differeniate non-SIP URL's
> which may not have a "@" eg (tel%3a555-1234@proxy)]
> 
> Is it worthwhile suggesting different methods for SIP and non-SIP 
> URL's ? Or KISS and just stick with the latter, more general method?

I would KISS. &:)  Personally, I prefer the
embed-the-uri-as-a-parameter method, but that's probably mainly
for aesthetical reasons (on simple URLs, one needs no escaping
at all).

One plus for parameters (although I guess the user part could
still be used, but...) that I just thought of allows proxy to
insert all the necessary information in the request only.  Say
I (a machine in sipfarm.net) receive the following:

    INVITE sip:[email-masked] SIP/2.0
    From: sip:[email-masked];tag=2718281828
    To: sip:[email-masked]
    Contact: sip:[email-masked]
    ...

I Record-Route and proxy downstream (illegal line wrapping for clarity):

    INVITE sip:[email-masked] SIP/2.0
    From: sip:[email-masked];tag=2718281828
    To: sip:[email-masked]
    Contact: sip:[email-masked]
    Record-Route: <sip:sipfarm.net;
      caller=sip:[email-masked];
      callee=sip:[email-masked]>
    ...

At some point later, I see a re-INVITE:

    INVITE sip:sipfarm.net;
      caller=sip:[email-masked];
      callee=sip:[email-masked] SIP/2.0
    From: sip:[email-masked];tag=3141592654
    To: sip:[email-masked];tag=2718281828
    Route: sip:[email-masked]
    ...

Looking at the From and To, I can determine that this is from
called to caller.

Granted, it's a little more work initially, and potentially
in subsequent requests (because of the From/To decision), but
it seems a little easier than inspecting and modifying
Record-Routes in any responses.

Thoughts?

 - Jo.