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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 23 Nov 2000 04:39:35 -0800

Hi Jo,
 
> Very nice -- it's cool that you've found a way to maintain
> "the Request-URI points to the ultimate destination" as an
> invariant.

I still don't see how this is the case. You just have two different URL's
located at the proxy server. I don't see they point to the ultimate
destination (unless I missing something fundamental). 
 
>   Each Record-Route header field contains a globally reachable SIP URL
>  that identifies a proxy server.  Any proxy that wishes to remain in
>  the signalling path of a call leg adds its own SIP URL to the
>  beginning of the list of these fields in a request.  This SIP URL
>  MUST represent an address that is reachable via UDP, and SHOULD
>  represent the calling UA (i.e., be derived from the Contact/From).

As above, I don't understand how it "represents" the UA in any sense outside
the proxy's internal implementation. I am not saying that this is a bad idea
but I do think this wording will cause a lot of confusion. Do you derive it
from the just the user part of the Contact/From ? What if the user name is
the same (jack@A <-> jack@B?)? Are you suggestign we put an escaped copy of
the whole Contact/From into the username portion of the Route ? Why not just
say 

"This SIP URL MUST represent an address that is reachable via UDP, and the
user portion SHOULD be distinguishable by the proxy as being destined for
the calling UA. The URL SHOULD also be distguishable from any previous
Record-Route entries added by the proxy (e.g., due to spiraling routes)." 

>  In addition, a proxy SHOULD modify its URL in the corresponding
>  response(s) to reflect the called UA (i.e., be derived from the
>  original Request-URI).  Requests between both user agents
>  involved in the call leg, in either direction, traverse this route.

> could also perhaps add some motivational text indicating how this
> behaviour helps to maintain the Request-URI semantic invariant.
> 
> > >  *** Should we remove this bit about 401 and 484?  It makes things
> > >      more complicated, and also what if a proxy has 
> collected a load
> > >      of WWW-Authenticate and Proxy-Authenticate headers into a
> > >      401 (Section 12.4 of bis2) -- the Record-Route could be 
> > >      arbitrary.

I have no opinion on this one.

> > >  *** I haven't said initial INVITE here, since wasn't there 
> > >      some talk about abstracting it for, say SUBSCRIBE/NOTIFY
> > >      purposes?

I agree that we need to make the "pre- initial INVITE" behaviour very clear
because in mind the descriptions in Sections 11 & 12 are not so clear on
this.

> > >  *** If no Contact, should add the From?

Is there a reason why we should change the existing behaviour ?

Cheers,

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: Thu, 23 Nov 2000 14:51:49 -0000

Robert Fairlie-Cuninghame wrote:
> I still don't see how this is the case. You just have two different
> URL's located at the proxy server. I don't see they point to the
> ultimate destination (unless I missing something fundamental).

They might not point to the ultimate destination, per se; but
the Request-URI will be meaningful enough to the proxy such
that it could reapply its initial routing decisions, if
necessary.

> As above, I don't understand how it "represents" the UA in any
> sense outside the proxy's internal implementation. I am not saying
> that this is a bad idea but I do think this wording will cause a
> lot of confusion.

I see what you're saying -- my wording is confusing upon reading
it back.  Hmmm...

> Do you derive it from the just the user part of the Contact/From ?
> What if the user name is the same (jack@A <-> jack@B?)? Are you
> suggestign we put an escaped copy of the whole Contact/From into
> the username portion of the Route ?

This is probably what I would do, in fact.

> Why not just say

Basically because I'd rather we imply as little as possible about
the format of this URL; however, I think we're getting warmer.

How about:
    This SIP URL MUST represent an address that is reachable via
    UDP, and SHOULD somehow be meaningful to the proxy, such that
    it could map the URL back to the calling UA (e.g., by embedding
    the Contact/From ha a parameter).
?

> Is there a reason why we should change the existing behaviour ?

I wasn't sure what the existing behaviour was...

 - Jo.