Subject: RE: [SIP] Record-Route consensus

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 21 Nov 2000 03:27:52 -0800

Jo, you're right, I was referring the to "new" old Record-Route scheme
presented in the bis draft not the "old" old RFC2543 R-R scheme. [ I also
admit to a fading memory of the old RFC specifics :) ] Its the Route
mangling in the _UAS_ (not the proxies) that is causing us the grief now
(ala the bis). The route mangling was to maintain the protocol invariant of
the Request-URI (not very well) which even JR agrees might be causing more
pain than its worth.

One could say "why bother worrying about backwards compat - nobody
implemented the Route mangling anyway". Is this true? Or have a sufficient
number of UAS's implemented this to make it worthwhile to put some thought
into detecting if Route mangling will not occur ?

If it is not worthwhile worrying about bis implementations, then the fix is
simple, right? Each proxy simply puts its own globally routeable address
into the Record-Route URL and then go back to the simpler RFC2543 behaviour.

Otherwise, well we also have to have the UAS do something indicative that
the "new old old" behaviour is implemented. 

I think I can guess what the consensus will be, "Don't worry, be happy." I
think I would tend to agree. :) 

[As an aside, IMO, the argument that a mutual trust relationship is required
to ensure a proxy stays in the signalling path, doesn't apply to justifying
why something can't be _expected_ to succeed between a set of co-operating
(ie, non-intentionally-malicous) UA and proxies].   

Regards,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 
  
> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 6:31 PM
> To: Fairlie-Cuninghame, Robert; 'David Shrader'; SIP List
> Subject: RE: [SIP] Record-Route consensus
> 
> 
> 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
> > 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'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.
> 
> > 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?
> 
> 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.
> 

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 21 Nov 2000 11:58:38 -0000

Robert Fairlie-Cuninghame wrote:
> admit to a fading memory of the old RFC specifics :) ]

Oh, right! &:)

> Its the Route

> the "new old old" behaviour is implemented.

Very much so.  I was basically working on the premise of "screw
the current bis". &:)

As you've noted, I don't think we can have one solution which will
work across the board.

> [As an aside, IMO, the argument that a mutual trust relationship
> is required to ensure a proxy stays in the signalling path, doesn't
> apply to justifying why something can't be _expected_ to succeed
> between a set of co-operating (ie, non-intentionally-malicous) UA
> and proxies].

True.  True.

However, I think it's likely in practise that UAs will be
"required" to conform to RFC N (where N is the next SIP RFC,
or whatever), if they are going to be used in certain networks;
this is what I was alluding (albeit poorly) to.

Cheers,

 - Jo.