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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 27 Nov 2000 19:03:18 -0800

Hi guys,

This whole non-SIP Route concept is scaring me <grin>. I whole hearted agree
that when Route is used, the routing relationship is no longer just to the
original destination but rather to the network location of the next Route'd
proxy. [For this reason I am having misgivings about how worthwhile
Jonathan's invariant that the Request-URI in some form represents the final
UA is. If it just represents the direction ok I can live with that.] 

Take the tel case: you are not interested in routing to the tel: of the
final destintion but rather in routing to the next proxy that wanted to
remain in the path - through a globally udp-reachable address. For instance,
UAC->P1->P2->P3->P4->UAS. If P3 Record-Routes with a some URL scheme scheme
only known by adacent proxyies P2 and P4 then the call will fail because
either the UAC or P1 must also be able to route to P3 based on the Route.

So to patch that problem a raddr parameter is suggested - that all UA's and
proxies must understand. However, the raddr must still specify a globally
udp-reachable address for things to work (otherwise you run into the same
problem). So what's the point? Just KISS and stick with SIP URL's. I think
the simpler something is, the more likely it will be to work across
everyone's SIP devices - and this is somethign you want to work.

I would make the same argument for non-SIP Contacts (used for routing SIP
calls not for providing alias/alternate route possibilities). 

IMO Request-URI's are different due to that fact that the Request-URI can be
translated as it traverses a network - so you only have to know whether or
not an adjacent proxy/UA supports a certain (non-SIP) URL scheme. This is
NOT TRUE after the initial INVITE and you also no longer want to do
network-independent routing. 

As an aside, we were discussing earlier that about route parameters and
angle brackets. A couple of peopel agreed that for

Record-Route: <url>;rr-param

A UA or proxy does not need to include rr-param's when buidling the
Request-URI (ie, the Record-Route header parameters). If you want parameters
to be passed into the Request-URI, they should go _inside_ the angle
brackets(ie, Record-Route Request-URI parameters). This follows standard URL
rules and is intuitive given that the Request-URI cannot contain angle
brackets.

I look forward to hearing your point of view on this.

Regards,

Robert.

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

> -----Original Message-----
> From: Billy Biggs [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2000 1:29 AM
> To: Sean Olson
> Cc: Jonathan Rosenberg; Jo Hornsby; [email-masked];
> [email-masked]
> Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus)
> 
> 
> Sean Olson ([email-masked]):
> 
> >>   Sorry, let me be more specific.  Say I use a non-SIP URI 
> in the RR
> >> (or Contact) of:
> >>
> >>   <tel:911>;raddr=udp/22.33.44.55:5060
> >>
> >>   My only choice for request-URI is "tel:911", but this does not
> >> convey the destination of the request.  Since you now can't route
> >> based on request-URI, you can't use an outbound proxy, stuff breaks
> >> in general.
> > 
> > Why doesn't the outbound proxy RR?
> 
>   It does, but what if you call me directly and not through 
> my outbound
> proxy?  The INVITE transaction completes without my outbound 
> proxy being
> placed in the Route.  When I send a BYE or whatever, it will go to the
> outbound proxy, and now your URI loses its significance.
> 
>   That's very brittle.
> 
> >>   2. Should we standardize an raddr RR parameter and allow this to
> >>      be used for SIP URIs?
> >>
> >>      I say no.  In general this technique breaks with outbound
> >>      proxies or transparent proxies.  If necessary, this could be
> >>      standardized outside of the SIP spec.
> > 
> > Standardizing this as an extension doesn't really help. I'm curious
> > why transparent proxies would be in the signalling path.  Outbound
> > proxies should RR (am I missing something here?)
> 
>   Transparent proxies are useful when you want to divert SIP requests
> going out to the internet to go to a special firewall proxy.  This is
> common with HTTP.
> 
>   SIP and HTTP are elegant in their proxy-awareness.  Messages can be
> forwarded between proxies without information loss.  However, with an
> raddr or whatever, now the IP layer has significance to the meaning of
> the message, which breaks the model.
> 
> >>   [...] but a client should know to convert a tel URI to a SIP URI
> >> like phonenumber@gateway.  I thought that was the point of them,
> >> not to use them as a Request-URI.
> > 
> > In this specific case, it may or may not be possible for the UAC to
> > translate the tel: URI into a SIP URI. (How does the client 
> know which
> > "domain" owns a specific number?) This is where an outbound 
> proxy may
> > play a role. In any case, it may be useful in certain cases to use a
> > Request-URI which is not directly routable.  A proxy downstream can
> > translate this into a Request-URI which is routable.  [...]
> 
>   But now the client and the outbound proxy are together acting as a
> single logical client.  This technique, translating a tel: URI into a
> SIP URI, can only be done at the edges, and does not work 
> unless you are
> sure you are not going to hit some transparent proxy in the middle.
> 
>   My point is that URI schemes other than SIP are useful for internal
> purposes.
> 
> -- 
> 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

---

From: Billy Biggs <[email-masked]>
Date: Mon, 27 Nov 2000 22:45:25 -0600

Some brief comments:

> Take the tel case: you are not interested in routing to the tel: of
> the final destintion but rather in routing to the next proxy that
> wanted to remain in the path - through a globally udp-reachable
> address. For instance, UAC->P1->P2->P3->P4->UAS. If P3 Record-Routes
> with a some URL scheme scheme only known by adacent proxyies P2 and P4
> then the call will fail because either the UAC or P1 must also be able
> to route to P3 based on the Route.

  If P2 and P4 Record-Route then this isn't a problem.

  Allowing unknown URI schemes in the RR/Contact/ReqURI is cheap.
However, they only work in a strictly engineered private network.

> IMO Request-URI's are different due to that fact that the Request-URI
> can be translated as it traverses a network - so you only have to know
> whether or not an adjacent proxy/UA supports a certain (non-SIP) URL
> scheme. This is NOT TRUE after the initial INVITE and you also no
> longer want to do network-independent routing. 

  There might be a transparent SIP proxy between you and this
destination which will snarf the message, at which point you lose the
ability to route based on request-URI.  This is unacceptable.

> As an aside, we were discussing earlier that about route parameters
> and angle brackets. A couple of peopel agreed that for
> 
> Request-URI (ie, the Record-Route header parameters). If you want
> parameters to be passed into the Request-URI, they should go _inside_
> the angle brackets(ie, Record-Route Request-URI parameters). This
> follows standard URL rules and is intuitive given that the Request-URI
> cannot contain angle brackets.

  You are correct that rr-params don't get copied into the request-URI.
This is why placing routing information in rr-params is broken.

  This does not mean that rr-params are useless.  They may be useful for
extensions which require special behavior from the hop before.

  Note that parameters aren't standard across URI schemes.  As such, we
can't define, say, an "maddr" parameter and expect it to have
significance in a tel URI.