Subject: [SIP] Contact in OPTIONS

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 May 2000 11:04:39 -0400

Currently, Contact is optional for OPTIONS. While this is harmless, it
is not quite clear what this Contact would mean in this context. It
could mean "send future requests here", if used within an existing call.
Any preferences?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 May 2000 11:35:30 -0400

To date, OPTIONS has been one of those "outside of the call" methods
which has no impact on call state. Changing the address for routing
subsequent requests was something I thought was handled through
re-INVITE; having this also happen through OPTIONS seems to add another
thing to check for, and also means that OPTIONS now has an effect on
calls, when it didn't before.

A reasonable use for Contact in OPTIONS (and its response) is to list
the communications means available for establishing new sessions or
other things. For example:

OPTIONS sip:[email-masked] SIP/2.0
From: sip:[email-masked]
Contact: sip:[email-masked], http://www.cs.columbia.edu
 ,mailto:[email-masked]

and the reply contains Contact headers with the same thing.

-Jonathan .

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 26 May 2000 09:58:07 +0100

Hullo,

> calls, when it didn't before.

Agreed.  If a Contact header in an OPTIONS request/response could
affect message routing, wouldn't this imply a potential need to
add a Record-Route header?

Actually, that reminds me: at the Bake-Off, there was some discussion
about the use of Route/Record-Route; I think the following points were
raised:
    a) any old SIP Entity can "force" a Proxy to send a message
       anywhere, just by inserting a Route header;
    b) does Record-Route only apply to the next Request (I think
       that this is now confirmed by the bis draft);
    c) is there any way to use the Record-Route mechanism to
       store state.

I guess a) can be solved by Authentication, or similar, but it
could also be solved by c).  Has there been any sort of progress/
thoughts/whatever on this at all?

Also, what is the motivation behind:
    "It [Record-Route] is also added by any proxy that translates
     between TCP and UDP or vice versa."
(Section 6.34.1 of May bis)

Cheers,

 - Jo.

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 26 May 2000 10:14:12 -0500 (CDT)

>thoughts/whatever on this at all?

Actually, I thought B was somewhat controversial; I'm surprised
that it was changed without a lot of discussion on the list.
Personally, I have no objection to the new behaviour; I just
severely dislike the fact that it is not backwards compatible
with the 2543 draft. Specifically, 2543-based call-stateful
proxies (including firewalls) will break in all kinds of ways
with 2543bis-based clients, if this change is finalized. Yuck.

Perhaps we can add something to the message so that 2543bis based 
clients can tell that the "new" behavior is being used?

>(Section 6.34.1 of May bis)

Presumably, this function (TCP/UDP translation) would be provided
only if the clients couldn't talk to each other directly (e.g.
one is TCP only, and the other is UDP only). In this case, the
proxy must remain in the path to continue to provide TCP/UDP
translation for the duration of the call leg.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 26 May 2000 16:47:31 +0100

> translation for the duration of the call leg.

Yes.  A colleague (hi James!) suggested much the same.

It does potentially seem to be a little bit of a shame, however;
I can imagine a chain of proxies presenting a path that alternates
between UDP/TCP with User Agents talking UDP (or TCP) at either end.

Of course, I'm at a loss for anything better.

Ah well,

 - Jo.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 26 May 2000 10:55:27 -0500

"Adam B. Roach" wrote:
> >about the use of Route/Record-Route; I think the following points 
> >were raised:
[...]
> with 2543bis-based clients, if this change is finalized. Yuck.

I agree with Adam here.  RFC2543bis does state that this "...field is
added to a request by any proxy that insists on being in the path of
the next request for the same call leg".  I liked the RFC2543 behavior
better when the field was added to a request by any proxy that insists
on being in the path of _subsequent_ requests.  This will break existing
proxy behavior.

I am sure there are reasons why the per-request model was chosen in 
RFC2543bis?  Could someone refresh my memory with the most pressing 
ones?

Thanks,

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
IN Architecture and Internet Software Group
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 26 May 2000 12:25:54 -0500 (CDT)

>RFC2543bis does state that this "...field is
>on being in the path of _subsequent_ requests.

This just jogged my memory about something else that might need
to be addressed in the case that "Record-Route" applies to only 
the next transaction, somewhat akin to re-INVITE glare. 

We need to closely examine the implications of requests crossing
on the wire; under these circumstances, the "next" transaction
is something of an ambiguous concept. I beleive this could lead
to some pretty spectacular headaches. In particular, think
of two clients with two proxies between them. If requests
cross between the two proxies... my head hurts thinking
about trying to reconcile the record-route state of all
four nodes.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 May 2000 13:58:29 -0400

> with 2543bis-based clients, if this change is finalized. Yuck.

Consider the inclusion in 2543bis as an incentive to reach closure. It
might help to provide real examples where Record-Route is essential and
whether they'd be better off with next-request or rest-of-call
semantics. Firewalls clearly fall into the rest-of-call class.

> translation for the duration of the call leg.

Since then, some additional discussion seems to indicate that things get
a lot easier if we require UAs to speak UDP as the lingua franca.
Otherwise, we can't satisfy the goal of simply plugging in a bunch of
SIP phones and setting up calls, without a proxy.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 26 May 2000 13:27:49 -0500

> might help to provide real examples where Record-Route is essential 
> and whether they'd be better off with next-request or rest-of-call
[...]

As do call-model mapping proxies; i.e. SIP proxies which provide 
services based on a mapping of foreign call models.  Some of the work
we have done in this domain takes advantage of the "rest-of-call"
semantics by having the proxy inject a Record-Route in the first INVITE 
message and being guaranteed that subsequent requests (ACK, CANCEL or 
BYE) and responses (especially 200 OK) will come through it.

Regards,

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 27 May 2000 23:26:09 -0400

Another application I am aware of for record-routing, generation of call
detail records for proxies fronting a gateway, also requires it to see
all requests.

Seems like consensus so far to keep the current semantics.... anyone
object?

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 May 2000 01:47:53 -0400

> SIP phones and setting up calls, without a proxy.

To be specific, the proposal is that UDP support in UA transition from
SHOULD to MUST, so that:

1. UAs SHOULD support TCP, MUST support UDP
2. proxies MUST support TCP and UDP

The transport parameter in the Contact and Record-Route headers then
becomes the preferential choice; if not supported, you can always fall
back to UDP.

-Jonathan R.

---

From: Lars Berggren <[email-masked]>
Date: Mon, 29 May 2000 11:46:21 +0200 (CEST)

> semantics. Firewalls clearly fall into the rest-of-call class.

I recall an earlier discussion on the list where arguements were made that
the next-request behaviour would help a UA that crashes, reboots and
receives a re-INVITE for the call. The INVITE is designed so that it 
carries the information necessary to join the session regardless of
whether you know about previous requests or not. The next-request
mechanism would adhere to that design decision.

Also, in favour of the next-request behaviour, if the route can be changed
as the call progresses, I guess it can be useful. A proxy might want to
step out of the signalling path for example, but I don't have any real
world example on this.

However I also dislike the fact that the next-request mechanism is not
backwards compatible.

/Lars

Lars Berggren       <mailto:[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 May 2000 09:35:02 -0400

> However I also dislike the fact that the next-request mechanism is not

One possibility to increase robustness in the face of restarts might be
to have proxies insert Record-Route in every request. That way, the
rebooted component will still get the right information. This would seem
to be backward compatible. In this model, once a proxy adds itself to
the route, it cannot delete itself, i.e., *not* including does not imply
dropping out. Also, changing RR entries (for example, changing the maddr
part) could not be guaranteed to be respected by the other side.

Would this work?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 May 2000 22:17:11 -0400

> part) could not be guaranteed to be respected by the other side.

This definitely works. Basically, what it means is that so long as a UA
has state for the call, it keeps the original route and does not try to
update. If, however, it crashes and restarts, it uses whatever it gets
in the request. This would allow it to do a partial reconstruction of
the route - "better than nothing" kind of thing, with increasing
performance as this feature is spread.

In addition to this, we can define an explicit "remove me" record-route
entry. Something like:

Remove-Route: <sip:user@host;maddr=1.2.3.4>;remove=true

Proxies would add this when they want out. A UA not understanding this
will ignore out continue to use the old route, but a new UA would know
that this means to remove it from the Route in the next request. I think
this is also backwards compatible. 

Both of these mechanisms combined (remove-route and adding record-route
for mid-call messages) has the desired result of being backwards
compatible, providing for restarts after crashes, and allowing proxies
to remove themselves during a call.

-Jonathan R.

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 30 May 2000 09:41:57 +0100

Gentlemen,

> > Since then, some additional discussion seems to indicate that things
> > get a lot easier if we require UAs to speak UDP as the lingua franca.

So are we saying that adding a Record-Route header is not necessary
just because a proxy is acting as a TCP/UDP bridge?

> becomes the preferential choice; if not supported, you can always fall

Hmmm... isn't the implication of this that servers should ensure
that for every TCP port listened on (apologies for the
socket-oriented terminology), they have also bound a UDP socket
with the same port number?  Furthermore, these ports should have
the same semantics?  (I can imagine a proxy that exhibits different
behaviour on different ports.)

Is this ever going to be a problem?  (I suspect not, but it prob.
needs to be stated, if not already.)

 - Jo.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 May 2000 18:05:50 -0400

> just because a proxy is acting as a TCP/UDP bridge?

Yes. 

> behaviour on different ports.)

Yes, I suppose this is the implication. This is needed even if you
assume everyone doesn't speak UDP, and then proxies which translate must
record-route. 

> needs to be stated, if not already.)

If you want different behavior on different ports, thats fine. All it
means is that on a particular port, the behavior for UDP and TCP would
need to be the same.

-Jonathan R.