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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 24 Nov 2000 03:19:05 -0800

Jo,

> > > 
> > > ([email-masked];maddr=proxy, [email-masked];maddr=proxy)
> > >
> It works as long as the Request-URI doesn't already have an
> maddr parameter. &:)
> 

Request-URI's can't have maddr parameters but yes for the callee's Contact
this might be an issue. 

> > 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).
> > > 
> > (sip%3aA%64originating.com@proxy, 
> > sip%3aB%64server12.terminating.com@proxy)
> > ?? 
> > 
> 
> 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:

There will also be problems when the URL contains escaped characters that
have significance in the original URL (eg @,=,;). You have no way of telling
why the character was escaped. In my opinion this is the sort of thing that
makes a behaviour brittle, eg, if the proxy actually relies on correctly
recovering the original uri for routing purposes. [so yes a parameter is
better in my view as well).

> 
>     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.

Only this doesn't provide you with the original request-uri/Contact if you
want to use it for routing purposes (as the caller and callee fields are
built up from the To and From).

I still maintain that embedding the URI into user part still doesn't
represent the calling or called UA's - to everyone else they are just
arbitrary user names located at the proxy. So how does that help with the
desired invariant property? I beleive using parameters would be better. Eg,
placing the following RR header in the forward request

Record-Route: <caller@proxy;rr-uri=sip:[email-masked]>

and this in the response 

Record-Route: <callee@proxy;rr-uri=sip:[email-masked]>

is much less brittle than trying to embed the URL in the user part. Of
course, if the proxy is storing full state then rr-uri is not required.

As for maddr handling: If the proxy is required to add the rr-uri parameter,
then I think the proxy must also replace any maddr with a "rr-maddr"
parameter so that the outgoning request-URI is faithfully recreated. Of
course, once again this is only needed if the proxy is not keeping full
state. Ie, it is the responsibility of the actual implemenation to reproduce
the same routing action.

Eg, if your example was instead (with same routing 

>     INVITE sip:[email-masked] SIP/2.0
>     From: sip:[email-masked];tag=2718281828
>     To: sip:[email-masked]
>     Contact:
sip:[email-masked];maddr=machine35.cyber-cafe.com;yadda=blah

Then I would suggest the following Forward RR could be generated

Record-Route: <callee@proxy;
			rr-loop=1;
			rr-uri=sip:[email-masked];
			rr-maddr=machine35.cyber-cafe.com;
			yadda=blah> 

Once again, all we can do is provide a recommendation for proxies not want
to keep full state. So all we have to specify in the spec is characteristics
of what the base user@host is, right? 

Regards,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 24 Nov 2000 13:39:42 -0000

Robert wrote:
> Request-URI's can't have maddr parameters but yes for the callee's
> Contact this might be an issue. 

Actually, this is no-longer true: Request-URIs are now allowed
to contain maddr; From/To are still not (see bis).

> Only this doesn't provide you with the original request-uri/Contact
> if you want to use it for routing purposes (as the caller and
> callee fields are built up from the To and From).

My example was dull.  I had actually copied the Contact to the
callee parameter, and the Request-URI to the caller parameter;
unfortunately, the Request-URI happened to be the same as the
To.

> arbitrary user names located at the proxy.

I so don't disagree.  Say we have the following scenario:

    A --- P1 --- P2 --- B

Even on the initial INVITE, the Request-URI that P2 sees maybe
completely different from Request-URI that that P1 sees (imagine
that I'm on holiday and thus I've set up call forwarding to a
close friend).  Thus from that perspective, an arbitrary
Record-Route URI that only makes sense to the proxy that inserted
it is no different.

> So how does that help with the desired invariant property? I
> beleive using parameters would be better.

I don't think it matters how the URI is formed, as typically
it's only going to make sense to the proxy that inserted it
(unless we come up with a BCP, or sommat).

I think when I talk about this invariant, I don't necessarily
mean that the Request-URI along the entire route would be
routable by an arbitrary proxy; what I mean is that the
Request-URI would be routable at the salient proxy.

I think what Jonathan didn't like -- and I wasn't happy about
it, either -- was that in the reverse direction, the Request-URI
could in no way ever have been useful in finding the calling
UA (save the case that the calling and called UA were the same,
perhaps).  With the sorts of things being proposed now --
having a different URI on request and response, or somehow
embedding the caller, say -- this is no longer the case.  Sure,
it's likely that only the proxy that inserted the URI will
understand it, but that's in no way atypical, and I feel
still satisfies the invariant.

> As for maddr handling: If the proxy is required to add the rr-uri 
> parameter, then I think the proxy must also replace any maddr with
> a "rr-maddr" parameter so that the outgoning request-URI is
> faithfully recreated.

I'm not sure why this is needed?  Couldn't we just do something
like:
  sip:[email-masked];maddr=library.sunnydale-high.edu
to
  sip:proxyfarm.net;caller=sip:[email-masked]%3B
  maddr%3Dlibrary.sunnydale-hig.edu

Or is there some subtle parsing point that I'm missing?

> Once again, all we can do is provide a recommendation for proxies
> not want to keep full state. So all we have to specify in the spec is 
> characteristics of what the base user@host is, right?

I don't think we even need a user.

 - Jo.