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

From: Gordon Ledgard <[email-masked]>
Date: Wed, 11 Jul 2001 09:15:16 -0400

I love it. It's clean. Its neat.

I haven't thought this part out, but couldn't you also then
let proxies along the path replace the To header with normalized
addresses? Could this be part of a possible solution to our
"who called me?" problem with applications?

Gordon R. Ledgard

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2001 2:30 AM
> To: [email-masked]'
> Subject: [Sip] another modest proposal: change call-leg ID
> 
> 
> 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
> 

_______________________________________________
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: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 11 Jul 2001 09:44:06 -0400

Gordon Ledgard wrote:

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

This would only be needed in those cases where the UAC violates the
existing definition of call legs, which are presumably rare (overlap
dialing, possibly). All the other cases, such as call forwarding to C
and then INVITEs to C, are more corner cases that work oddly right now.

I think it would be worth considering if we can avoid the proliferation
of new identifiers and can spell out the cases where existing things
break.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs