Subject: RE: [SIP] Record-Route consensus

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 21 Nov 2000 01:57:35 -0800

DO that would _really_ confuse existing Record-Route proxies.

We have a few options:
1) Scrap current mechanism completely and come up with something that works
properly.
This should have the benefits that new proxies will be ensured of the
correct behaviour but it is not backwardly-compatiable with the old proxies
(preferably violently so).

Or 
2) Cobble something together from old record-route system so that:
a) old Record-Route proxies can still exist in the path (with known
problems), but
b) newer proxies can detect that the UAS will construct the reverse Route
correctly and
c) that older proxies will forward the Route entries correctly (assuming
they implemented the spec correctly).

Or lastly,
3) Cobble something together from old record route system so that:
A proxy can't tell if the UAS or other older proxies are going to screw
something up by using the old record-route behaviour.
This is the worst possible solution.

I think the current suggestions only fall into the last category which gives
you the worst of both worlds. Think about it, if a proxy wants to be
Record-Route'd there is a usually a reason for it. So it is next to useless
if the proxy can only be "semi-sure" that it will correctly receive reverse
requests. 

IMO opinion we need to come up with a RR proposal that is either
pro-actively _not_ backwardly compatiable or that the proxy can at least
detect that an older Record-Route scheme is being used by the UAS and/or
other proxies.

I have yet to hear suggestions falling into the second category..... so
here's mine: <grin>

- If the UAS receiving the Record-Routes was to put a special contact
parameter into it's Contact then this would at least solve the
"non-detection problem" of downstrea, proxies. 
- The UAS only changes the user@host:port part when building the reverse
Route header (from From or COntact). This leaves all R-R parameter. This
means that non-SIP Request-URI's should be work (and is backwards compat).
- I beleive an older proxy would/should still pass the Record Route
parameters onto the next hop (in the Request-URI) as long as you don't use
angle brackets in the R-R header.  That is, the record route parameters are
actually treated as "other" URL parameters in the Request-URI (which is
legal).

This I think should fall into the second (most preferable) category.

Comments?

Robert.

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

> -----Original Message-----
> From: David Shrader [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 12:59 PM
> To: SIP List
> Subject: Re: [SIP] Record-Route consensus
> 
> 
> Where do we stand on which server removes the Route header? 
> If I recall, the
> current spec says that the preceding server remotes the route 
> header for the
> next destination. OTOH, I also saw posts suggesting that the 
> server remove
> its own Route header (like the Via header).
> 
> David
> 
> ----------------------------
> David Shrader
> Master Consultant, Inc.
> [email-masked]
> http://www.EyeForTheFuture.com
> 
> > From: Billy Biggs <[email-masked]>
> > Date: Mon, 20 Nov 2000 09:55:59 -0600
> > To: Jo Hornsby <[email-masked]>
> > Cc: Sean Olson <[email-masked]>, 
> "Fairlie-Cuninghame, Robert"
> > <[email-masked]>, SIP List <[email-masked]>
> > Subject: Re: [SIP] Record-Route consensus
> > 
> > Jo Hornsby ([email-masked]):
> > 
> >> Right.  So we're saying remove the bit where the bis specifies that
> >> the Request-URI is copied into the Record-Route, and 
> instead note that
> >> the proxy is free to put any SIP URL in (of course, it should be
> >> routable); and also remove the bit where the bis specifies 
> the Route
> >> Request-URI mangling by the called UA.
> > 
> > Totally.  It should put in some SIP URI that is routable in both
> > directions.
> > 
> >>> Basically, you're just proposing that we don't allow non-SIP URIs
> >>> in the Route, and I think this is completely reasonable.
> >> 
> >> Agreed.  After all, we already say that a proxy is not allowed to
> >> mandate TCP (via the transport parameter) in Record-Route; allowing
> >> non-SIP URIs, I would say, is orders of magnitude more painful.
> > 
> > Dude, you rock my world.
> > 
> > Now, where's Sean Olson's argument? :)
> > 
> > -- 
> > Billy Biggs, 3Com               Email: [email-masked]
> > http://www.div8.net/billy/      Phone: [email-masked]
> > 
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 21 Nov 2000 10:31:10 -0000

Robert Fairlie-Cuninghame wrote:
>
> We have a few options:
> 1) Scrap current mechanism completely and come up with something
> that works properly.  This should have the benefits that new
> proxies will be ensured of the correct behaviour but it is not
> backwardly-compatiable with the old proxies (preferably violently
> so).
>
> Or
> b) newer proxies can detect that the UAS will construct the reverse
> Route correctly and
> c) that older proxies will forward the Route entries correctly
> (assuming they implemented the spec correctly).
>
> Or lastly,
> A proxy can't tell if the UAS or other older proxies are going to
> screw something up by using the old record-route behaviour.

I'm not sure how you come to this conclusion.

If I requote 2543, section 6.29:

   The server copies the Record-Route header field unchanged into the
   response. (Record-Route is only relevant for 2xx responses.)

   The calling user agent client copies the Record-Route header into a
   Route header field of subsequent requests within the same call leg,
   reversing the order of requests, so that the first entry is closest
   to the user agent client. If the response contained a Contact header
   field, the calling user agent adds its content as the last Route
   header. Unless this would cause a loop, any client MUST send any
   subsequent requests for this call leg to the first Request-URI in the
   Route request header field and remove that entry.

If I were feeling particularly uncharitable, then I would say a
(calling) 2543-compliant UA that did not copy _all_ of the URI
parameters was seriously broken -- it had no business assuming
that it was allowed to mangle the Record-Route values in any
way.

Further, looking to section 2 of the same:

   The transport, maddr, and ttl parameters MUST NOT be used in the From
   and To header fields and the Request-URI; they are ignored if
   present.

   Headers: Headers of the SIP request can be defined with the "?"
        mechanism within a SIP URL. The special hname "body" indicates
        that the associated hvalue is the message-body of the SIP INVITE
        request. Headers MUST NOT be used in the From and To header
        fields and the Request-URI; they are ignored if present.  hname
        and hvalue are encodings of a SIP header name and value,
        respectively. All URL reserved characters in the header names
        and values MUST be escaped.

   Method: The method of the SIP request can be specified with the
        method parameter.  This parameter MUST NOT be used in the From
        and To header fields and the Request-URI; they are ignored if
        present.

Therefore, a 2543-compliant client (be it proxy or UA) again would
have no business removing any parameters that it did not recognise,
besides the ones listed above.  It's a bit of a shame that maddr
was included, but we don't actually need that parameter with this
proposal, anyway. &:)

> I think the current suggestions only fall into the last category
> which gives you the worst of both worlds. Think about it, if a
> proxy wants to be Record-Route'd there is a usually a reason
> for it. So it is next to useless if the proxy can only be
> "semi-sure" that it will correctly receive reverse requests.

This is true -- I find it very unlikely that 2543-compliant called
UAs would ever do The Right Thing when sending requests; however,
in the end, even ensuring that one is a pure 3000 (imaginary new
RFC) network, isn't enough in itself.

That is because UAs can still misbehave -- maliciously, or
otherwise.  Record-Route is a mechanism that allows proxies to
ask that they are kept in the signalling path; however, they
can't insist such that the signalling path will be torn down
if they are not.

If a proxy is to know that it's going to stay in the signalling
path, then it will be achieved with trust relationships, and
various networking magic.  Most often, this will probably
consist of talking to vendors/service-providers that offer
guarantees; and ultimately, I think that this is the best that
one can do.

> This I think should fall into the second (most preferable) category.

This will work -- of course.  It's just that I see no real need
to make the differentiation (old vs. new), when on paper (ignoring
bis (:&), we already have interoperation[0].

Cheers,

 - Jo.

[0] With new UAs that don't mangle the Route Request-URIs, of course.