Subject: [Sip] another modest proposal: change call-leg ID

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Jul 2001 02:30:12 -0400

Folks,

While we're on the subject of modest proposals, here is another that I've
been toying with:

  Change the definition of call-leg ID. Instead of To, To-tag, From,
  From-tag, and Call-ID, its *only* the tags and the Call-ID. That is,
  the ID no longer contains the URLs.

There are quite a few benefits from this:

1. A calls B, and its forwarded to C. C accepts, and later re-INVITEs. The
From field in this re-INVITE is NOT actually the identity of C, but rather,
B. This screws up the idempotency of SIP INVITE. The From field has one
meaning in INVITE, and another in re-INVITE. This makes defining policies
based on the From field more complex, since they no longer work properly for
re-INVITE. 

2. call-leg ID lookups in gateways are much faster now, since the tags and
call-ids are just strings. Matching is now case-sensitive string compares.
Much easier than URL comparison. 

3. Overlap dialing is easier. The reason we've had to send each digit as a
new call leg, is that we needed to change the To field and the request URI.
By definition, this meant a new call leg. Now, we can send all of that
within a single call leg. Much cleaner.

4. The Replaces draft benefits. We've already identified a need for the
Replaces header to identify the entire call leg thats being replaced. This
gets big when it carries two URLs, two tags, and a call-id. Now, we can
throw away the URLs. This shortens the header and makes matching of the
call-leg IDs easier.

5. It works with existing proxies.

THe main drawback, of course, is that this won't interoperate with rfc2543
UAs. Thats fixable with Supported; the UAC indicates Supported:
new-call-leg-id in the INVITE if it understands this. In that case, any
responses or re-invites that change the URLs include a Require:
new-call-leg-id. 

I fully admit that this may not be worth the pain. However, I'd welcome
comments from others on whether its useful to consider further.

-Jonathan R.

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

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 11 Jul 2001 20:55:03 -0400

> based on the From field more complex, since they no longer 

The Remote-Party-ID of the Privacy draft already 
provides this information if it is passed during 
re-INVITE transactions and reflects appropriate
changes when leaving trusted boundaries.

Allowing the To and From headers to be changed on 
a call-leg potentially could allow the Privacy 
draft to incorporate the rpi-token into the To 
and From without the need of the Remote-Party-ID 
header.  However I guess that proxies couldn't
change the certain headers if the message is
signed. 
 
> Much easier than URL comparison. 

This is a good enough reason for me.
  
> throw away the URLs. This shortens the header and makes 

Sounds good.
 
> responses or re-invites that change the URLs include a Require:

This works when the change occurs in the re-invite 
and it contains Require and Proxy-Require.  It doesn't 
work if the change is in the INVITE response unless 
the UAC added Proxy-Require to the INVITE.

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 13 Jul 2001 11:32:29 +0100

> There are quite a few benefits from this:
[...]
> 5. It works with existing proxies.

Uh.  I get the feeling that I'm going to look like a numpty
because of this, but won't this break older proxies that
attempt to be call-stateful by examining the whole From/To?

Not that I'm advocating this as an approach (although I'd
struggle to see a better way without the new Record-Route:
ing rules), you understand. &:)

> responses or re-invites that change the URLs include a Require:

Shame.  And I think this is the thing that bothers me most.
If there are going to be occasions where one will be unable
to change the From, then it hardly seems worth it.

Still, I guess it falls back to the (presumably unspoken)
knowledge that no Real Networks are going to have 2543
elements in them....

 - Jo.