Subject: RE: [SIP] Identification problem

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2000 01:58:42 -0500

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Monday, November 06, 2000 5:14 AM
> To: Jonathan Rosenberg
> Cc: 'Bertil Engelholm'; [email-masked]
> Subject: Re: [SIP] Identification problem
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > > Am I missing the problem? The other RR suggestions are
> > > certainly interesting ;)
> > 
> > The problem is that the unique via branch param allows you to
> > *differentiate* between each request, but there is no easy 
> way to know that
> > a request corresponds to a specific state machine. Thats 
> because (1) the
> > proxy immediately before and/or after P1 may not actually 
> record-route, so
> > the branch param in the original INVITE could be totally 
> different from the
> > one in the re-INVITE or BYE, and (2) proxy P1 has no way to 
> know what the
> > branch param for requests in the REVERSE direction will 
> look like after the
> > original INVITE.
> 
> I agree there is this issue but is it really a problem for 
> the spec? 

It depends. The problem here is that if the proxy has some state which is
different for each iteration of the request through the proxy, is there a
way to associate each request with the right piece of state? I think this is
a reasonable thing to expect to be possible, so the protocol should have
some way of supporting it.

Another potential solution is to slightly change the way Route headers are
constructed. Right now, the spec says:

----
If a UA finds a Record-Route header in a request received as a UAS, it
copies the Record-Route
maddr parameters and any port value, maintaining their ordering, to the
Route header field of future
requests issued as a UAC. Since the URIs contained in the Record-Route
header fields are not useful for
the reverse request path, the UA fills all other components of the Route
name-addr value with the name-addr
value found in the Contact or the From header field. The latter is used only
if there is no Contact
header field.
----

as I pointed out, this causes everything from the Contact/From to be copied
into Route, EXCEPT port and maddr. How about if we say that the Route
contains the user:password@host portion of the Contact/From, and everything
else is copied from the Record-Route? THis would include unknown URL
parameters.

The advantage here is that one could insert URL parameters into the
record-route, and get them back in the request URI. Not the prettiest way to
go. We could, as an alternative, simply mandate the State header in the bis
draft, which would provide a cleaner solution.

>> So, perhaps we should consider defining address and port record-route
>> parameters. These would only be set when the request URI contained a
non-SIP
>> URL. Proxies would use these parameters if present for routing instead of
>> the maddr and port in the URL.
>>
>> COmments? (I'm sure there are).
>> -Jonathan R.
>
>I like this approach except I would take it a step further and
>do this for all URLs including SIP URLs. This allows maddr to go
>back to its original intention for SIP URLs. Plus I hate special
>cases; this seems (nominally) easier to implement.

Conceptually that is clearly the better way. However, there is a backwards
compatibility problem. Older rfc2543 implementations will use the maddr to
forward (if they are working correctly, that is), but not an address
parameter of the Route header.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Sean Olson <[email-masked]>
Date: Tue, 07 Nov 2000 09:43:07 +0100

> parameter of the Route header.

This seems to be a backwards compatibility we can afford to break.
Will an older rfc2543 implementation really work with one based on bis
anyways? There seem to have been some substantial changes in the
mechanisms. At the very least, there is a syntactic change. (I had to
play this card because I believe implementations should handle this
change -- the addition of RR parameters)

/sean

---

From: [email-masked]
Date: 7 Nov 2000 17:59:56 -0000

> draft, which would provide a cleaner solution.
So, the State header will be a comma separated list (or multiple
state headers) of state ids
one per Route Header. However as one Route header is removed before sending
out the request, the corresponding State header is retained, only to
be removed by the subsequent proxy if it proceses the next route
header. In other words there should be n+1 State headers for
n Route headers in the request. This correlation process can
become tricky. Knowing whether the topmost State info is relevant
to the proxy can be difficult.

I would prefer to see this state info in the record route/route
headers.

Shiv

---

From: [email-masked]
Date: 7 Nov 2000 19:13:32 -0000

> else is copied from the Record-Route? THis would include unknown URL

Are we not going out of the way to retain the Request URI
to be the final destination. This has caused problems
is various contexts. Also an assumption is
being made in all cases is that the Request URI is routable.

What if a proxy receives a request with a URI that is not routable
by it. Consider an INVITE [email-masked]. The proxy receiving
this request may not be able to route this because zone pqr may
not be resolvable by this proxy, however if this request is
sent to stu.xyz.com it may be. I would like to see request URIs
indicate intermediate hops. I think the Request URI should retain its 
flexible flavor.

In another thread:

>Now, an interesting thing to note here. Lets say in this failure case, it
>was the called party that hung up. The proxy downstream from P2 (say, P3),
>pops its top Route, and tries to forward it to P2. But, that maddr >
(pointing
>to P2), generates an ICMP error. So, it looks up the host portion of the
>request URI in DNS and tries the SRV process from there. I will note that
>this will only succeed if, and only if, *THE REQUEST URI ALWAYS REFERS TO
>THE RESOUCE FOR WHOM THE REQUEST IS DESTINED*. Now, this relates to a
>previous thread. The issue there was how a UAS would construct the Route
>headers, and whether we should maintain this property that the R-URI 
always
>refers to the entity for whom the request is targeted. I originally felt
>this was critical, and was coming close to backing down. Now, it seems we
>have another case to back up my original claim that maintaining this
>property is important.

I would like to find out why resort to the Request URI when you
could do better by sending the request to the next 'Route' header. Are
we going out of our way to preserve the Request URI? What if it is
not routable.

Shiv

---

From: Neil Deason <[email-masked]>
Date: Wed, 08 Nov 2000 09:48:58 +0000

> to the proxy can be difficult.

It doesn't have to be done that way. The State header could very 
easily include a value by which the proxy can identify itself. 
In fact the DCS work has already proposed something like this:

   State           = "State" ":" 1#(host ";" state-token 
                                *(";" state-token))
   state-token     =  token ["=" (*token | quoted-string)]

See:
http://search.ietf.org/internet-drafts/draft-ietf-sip-state-00.txt

A State header is much cleaner than a hack which overloads 
the meaning of SIP URL params in Record-Route. That type of 
approach looks to have greater potential for future deficiencies.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 8 Nov 2000 11:24:48 -0000

Sean Olson wrote:
> > Conceptually that is clearly the better way. However, there is 
> > a backwards compatibility problem. Older rfc2543 implementations
> > will use the maddr to forward (if they are working correctly,
> > that is), but not an address parameter of the Route header.
> 

Hmmm... this backwards compatibility thing is a pain, but how
about this:

2543 (Section 6.29) currently states:

    The Record-Route request and response header field is added to a
    request by any proxy that insists on being in the path of
    subsequent requests for the same call leg. It contains a globally
    reachable Request-URI that identifies the proxy server. Each proxy
    server adds its Request-URI to the beginning of the list.

[Note that the text says the proxy adds its Request-URI; it
doesn't say any more than that, so it doesn't seem unreasonable
to assume there is freedom for perhaps more exotic URI than
one might normally find.]

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

[I would highlight the "unchanged" in this sentence.]

    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.

[And here we have the client sending to the Request-URI in popped
Route.  Again, it doesn't seem unreasonable to assume that the
Request-URI is copied verbatim; the only slight change might be
removal of any of (maddr, transport, ttl) parameters, since these
were not allowed in the Request-URI in 2543 (Section 2, just
before "Headers:".]

If the motivation behind retaining backwards compatibility is
purely a "we're going to be breaking the spirit of the RFCs/IETF",
then this may be a solution...

Instead of proxies copying the Request-URI, and mangling the
port and maddr, why not just get them to put _their_ SIP URL in,
and make the Request-URI a parameter of the SIP URL (suitably
escaped, of course).

So for instance, say I am an example.com proxy, listening on
port 6000.  I get the following:

    INVITE sip:[email-masked] SIP/2.0
    ...

I then forward this as (Alice gets about a bit):

    INVITE sip:[email-masked] SIP/2.0
    ...
    Record-Route: <sip:example.com:6000;uri=sip:[email-masked]>
    ...

Now if a 2543 client sends a subsequent request in the
caller -> callee direction, this proxy should see:

    INVITE sip:example.com:6000;uri=sip:[email-masked] SIP/2.0
    ...

which should be enough information. &:)

Now I know we have questioned whether the UA or proxy or whatever
will copy the entire Request-URI, but the spec certainly doesn't
say that only the user@host:port is copied, so I don't see this as
a valid argument.

If, OTOH, we are looking at backwards-compatibility from a "work
with existing SIP Implementations" standpoint, then I have to say
that so much of Record-Route wouldn't have worked anyway (the
spec says nothing about building Route:s in the callee -> caller
direction), is it really worth worrying?

With this approach, we can write into bis, say, that the called
UA, when forming requests, renames all "uri" parameters to
"original-uri"; and appends a new "uri" parameter with the value
of the Contact:/From:.

We now have the resilience that Jonathan was addressing (thread:
"failure of proxy), since each proxy along the Route can see
the final destination.  And also, if the request spiralled,
we know where on the Route we are (since we have retained the
original Request-URIs, too).

Now I know that this is a significant change, but as far as I can
tell, realistically, no proxy will as yet have been able to
Record-Route properly and/or remain call stateful, because we
are still finding bugs.  Thus it doesn't seem as if there can be
real objections to making such a changes, since hopefully they
are changes towards having a fully-working mechanism (okay, I
guess we think it works now, but it can't be more than 3 months
since we spotted that Record-Route: can break in the reverse
direction when a request has spiralled; how mature can
implementations possibly be?)

Thoughts?

 - Jo.

---

From: Sean Olson <[email-masked]>
Date: Wed, 08 Nov 2000 13:50:21 +0100

Some ramblings on the subject.
/sean

Jo Hornsby wrote:

<snip>

> and make the Request-URI a parameter of the SIP URL (suitably

<snip>

> say that only the user@host:port is copied, so I don't see this as

But this should be clarified. The UA/proxy MUST copy the entire URI
from the Route: header into the Request-URI without modification or
omission.

> direction), is it really worth worrying?

I agree completely with this sentiment.

> "original-uri"; and appends a new "uri" parameter with the value

I'm not sure I see a need for three URIs in this case. You
have in the Route: header:

1) The URI of the Proxy  (the main URI)
2) The original Request-URI of the request that set up the Route: (the
"original-uri" parameter)
3) The URI of the Contact:/From: of the request that set up the Route: (the
new "uri" parameter)

Do we need the full expressive power of a URI (#1) to know how to route to
the proxy?
Do we need both 2 & 3? (Did I misunderstand your proposal?)

> the final destination.

But how does this help? Which is more important: ensuring that
a message follows the static route of Route:  -or- ensuring that the message

gets to the final destination?

> And also, if the request spiralled,

This is an interesting idea.

> implementations possibly be?)

Precis.

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 8 Nov 2000 13:09:19 -0000

> from the Route: header into the Request-URI without modification or

Oh very much so -- this should be clarified in the bis -- but
we'll have to deal with the fact that it's not nailed down in
the spec.

> Do we need the full expressive power of a URI (#1) to know how to
> route to the proxy?

I think you may have misunderstood a subtle point that I'm
trying to achieve.  I think with this approach, we get the
behaviour that a heterogeneous (in the sense RFC 2543 and
state-of-the-art bis) network of SIP entities would work as
well as a network of purely 2543 SIP entities; that is,
Record-Route would work for requests in the caller -> callee
direction.  Additionally, we might even be lucky enough to
get Record-Route working in the callee -> caller direction,
although this would require that the caller was using a
state-of-the-art UA.

(This does assume that the entire URI is copied by 2543
entities, of course.)

The reason that I'm going to these lengths, I guess, is to
maintain just enough backwards compatibility.

> a message follows the static route of Route:  -or- ensuring that 
> the message gets to the final destination?

Probably depends on who I am.  If I'm the caller, I'd probably be
quite happy if the message got to its final destination and
"happened" to miss out all of my networks billing servers. &:)

But I understand what you're getting at (I think).  For all
intents and purposes, it's only the Route that matters; it
just gives me a warm fuzzy feeling to know that I'm also being
backed up by the Request-URI.

Cheers,

 - Jo.

---

From: Billy Biggs <[email-masked]>
Date: Wed, 15 Nov 2000 16:16:19 -0600

I think Jo was on the right track with his suggestion of adding a
"uri" parameter, but I do not agree that it is worthwhile to add special
processing requirements to support a shaky failover solution.

  I believe that each proxy can decide for itself how much state
information to put in a Record-Route URI, and to provide a URI which
will route back to an appropriate destination for requests in each
direction:

  Method 1, transactions must go through this proxy to get through a
            firewall, no state required:
  --> R-R: <sip:firewall-proxy.com>

  Method 2, state kept with no failover:
  --> R-R: <sip:[email-masked]>

  Method 3, state kept in shared database with friend proxies:
  --> R-R: <sip:magic-cookie@multi-dns-response-domain;maddr=specific-proxy>

  Method 4, need original request URI for internal state:
  --> R-R: <sip:sipproxy.com;orig-uri=sip:foo>

  Method 6, oldschool proxy, doesn't mess up algorithm, provides a
            failover only in one direction:
  --> R-R: <sip:orig-req-uri;maddr=myproxy>

  In each of these cases, the proxy chooses an appropriate URI based on
its needs for state or failure case.

  Jonathan brought up the "fundamental invariant":
 
> That aside, the motivation for doing this oddball combination was to
> try and preserve a "fundamental invariant" of SIP, which was that the
> request URI  should always refer to an entity that the request is
> actually addressed to.  [...]

  Personally, I think the request URI should reflect the next hop in the
Route and not the final destination, otherwise we will get problems with
transparent outbound proxies and clients that don't put the maddr in the
request URI.  Ugh.

  Also remember that in many Record-Route situations, the final
destination is not reachable except through the proxy.

  I don't think it is worthwhile to overcomplicate the protocol just to
provide a _possible_ (and maybe unlikely) failover solution.

  I like the algorithm for clients and proxies to be dead simple:

  1. Proxies prepend an address to the front of the R-R list.
  2. If a client receives a R-R in a request, it copies it to the Route
     directly and then appends the Contact.
  3. If a client receives a R-R in a final response, it reverse copies
     it to the Route and then appends the Contact.
  4. When a client sends a request, it pops the first route and then
     uses it as the Request-URI.

  This algorithm is currently followed by multiple existing
implementations.

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]

---

From: Bertil Engelholm <[email-masked]>
Date: Fri, 17 Nov 2000 13:07:38 +0100

It's seems like we agree on removing the text from the
specification about overwriting the ROUTE-URI with the
URI from CONTACT/FROM. If this is done my problem to
identify the call state machine is solved. 

The other proposals you have concerns me a little bit.
Should we really use an URI for this kind of data. It
will probably work fine but it's to much of a hack in
my eyes. How about other types of URIs in ROUTE ?

As Jonathan pointed out some weeks ago there is no
maddr parameter in a TEL URL. So something needs to
be done to ROUTE to handle these kind of URLs. So
some parameter needs to be added to RECORD-ROUTE and
ROUTE (e.g. named 'raddr' for route address). 

Since this does not exists today it means that there
are no existing SIP implementations that can route on
a URI other than a SIP URL ? If this is true, how
backwards compatible do we need to be to fix this ?

So before a solution is decided this time may I suggest 
that it covers all known cases so we don't need to change
the RECORD-ROUTE/ROUTE behaviour again in the future.

/Bertil

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

---

From: Billy Biggs <[email-masked]>
Date: Fri, 17 Nov 2000 09:59:38 -0600

Bertil Engelholm ([email-masked]):

> The other proposals you have concerns me a little bit.  Should we
> really use an URI for this kind of data. It will probably work fine
> but it's to much of a hack in my eyes. How about other types of URIs
> in ROUTE ?

  It is not a hack:  You are sending the request to some state object on
a proxy so that it can update its state and then pass on the message.

> As Jonathan pointed out some weeks ago there is no maddr parameter in
> a TEL URL. So something needs to be done to ROUTE to handle these kind
> of URLs. So some parameter needs to be added to RECORD-ROUTE and ROUTE
> (e.g. named 'raddr' for route address). 

  You're suggesting that a proxy can put as its Record-Route:
  --> R-R: <http://my.proxy.com/rec-route-state>;raddr=proxy:5060

  Future requests are now sent like this:
  --> MYMETHOD http://my.proxy.com/rec-route-state SIP/2.0

  But IPly they are sent to the IP address proxy:5060

  This is dangerous because:

  1. The Request-URI is not routable by a transparent proxy in the
     middle.  If some firewall proxy snarfs the message, unless it
     records the real IP destination and port, it won't be able to route
     it to the appropriate destination.  This breaks the SIP model.

  2. This gets confusing, since in this case it is an http URI, but
     you're not sending it over http.

  I think that supporting this gives a small benefit at the cost of more
difficult implementation and non-compatibility with existing software.

  I don't believe it is worth it.

---

From: Sean Olson <[email-masked]>
Date: Fri, 17 Nov 2000 18:00:04 +0100

<snip>

>   I don't believe it is worth it.

I believe it is. The tel: URI is a good case for this.

There are three pieces of information that the Record-Route:
needs to convey:

1) What do you put in the Request-URI?
2) Where (IP address/port) do I send the message?
3) What is the context/state that the proxy associated with this RR?

The first item should be the addr-spec in the RR.
The second item should be separate and should be a parameter of the RR (not
of the addr-spec)
The third item can either be implied by the first item (provided it is
honored and not overriden
    by the Contact:) or it can be provided by a parameter of the RR.

Is this backwards compatible with RFC2543? No, because of the second item
which is
not a maddr parameter of the URI. This could be rectified for SIP URIs by
*both* adding
an maddr parameter to the SIP URI and adding a new raddr parameter to the
Record-Route:

Record-Route:
<sip:[email-masked];maddr=proxy13.money.com>;raddr=proxy13.money.com

I don't see a clean way to provide backwards compatibility to RFC2543. This
is
mainly because the mechanisms in RFC2543 are broken in subtle ways.

my two cents
/sean
--
Sean Olson <[email-masked]>
Ericsson Inc.