Subject: [Sip] Open Issue #140: use only tags for Call-leg ID

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 22:32:47 -0500

Issue:

An interesting proposal is to modify the definition of call-leg, so that is
the 
to tag, from tag, and call-id. This is different from the current definition
in 
that the URLs are dropped. 

Discussion:

This approach has some important benefits:

1. overlap dialing now becomes easier. Each digit can be added as a
re-invite 
with in the same call-leg (assuming re-invites can be sent within a call leg

before the previous completes - thats another issue) but with a different 
To/R-uri. Since the To URL is not part of the call-leg ID process, this new 
request can be part of the same call leg. However, the current proposal is
to not allow overllaping INVITE, so this may be moot.

2. A invites B, which is proxied to C. C sends a re-INVITE back to A. The
From 
field in the request from C is wrong! We'd like to maintain the idempotency
of 
INVITE, so that the from field is always the logical identity of the caller,
no 
matter when its sent. So, B could include its actual URL in the From field
of the re-INVITE. Since the call leg ID is based only on tags, this would
work.

3. Call leg lookups are now oodles easier, since they are just based on 
case-sensitive string compares. No more messy URL comparisons. However, its
worth noting that you can still do this anyway, since tags have to be
globally unique. That is, even though the spec says its the full
To/From/Call-ID, you could just use tags/Call-ID to index legs at a UA. What
you wouldn't be able to do is change the From/To URLs in subsequent
requests, as above in (2).

4. The Replaces header gets shortened; its now easier to identify the call
leg 
thats getting replaced. May not be a big deal.

5. This may work with existing proxies, but has compatibility issues with
existing 
UAs. A simple SUpported token would handle this, though.

Given that (1) is moot, (3) is possible without this proposal, (4) is not
too important, the only real benefit is (2), that you can send the right
From header in a re-INVITE. Now, an argument here is that anybody who makes
policy decisions based on the From header anyway is in trouble, since its
client supplied. Thus, you need to authenticate, and the credentials
provided (or the Remote-Party-ID header) are what you would use anyway. So,
who cares if the From header is not right in the re-INVITE anyway. 

Proposal:

So, given the limited utility, and the potential interop problems, the
proposal is to keep the current wording.

-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://www1.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: "Arunachalam Venkatraman" <[email-masked]>
Date: Wed, 5 Dec 2001 22:36:59 -0600

Jonathan
I think you meant to say
So, C(not B) could include its actual URL in the From field of the
re-INVITE.
Venkat

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Dec 2001 01:36:30 +0200

Hi,

Jonathan Rosenberg wrote:

> To/R-uri.

Actually this is what we do NOT want to do. We want every subsequent
INVITE to be part of a different dialog so that it gets routed
independently of the previous ones (it can take advantage of
services)... but this is another story.
 
> proposal is to keep the current wording.

Agreed.

Regards,

Gonzalo

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 6 Dec 2001 23:33:54 -0500

> proposal is to keep the current wording.

The proposal sounds fine.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Dec 2001 09:56:05 +0200

Hi,

First, I DO agree with the proposal.

Just a general To- and From header URL question, though...

ASSUMING that we would go for the proposal (only use the to tag, from
tag, and call-id), my question is: 

For what do we need the To- and From URLs for after the call has been
setup (after the initial INVITE transaction, that is)? Will it be needed
for any mid-session request, since the nodes use the established route
to forward the messages?

So, an INFO could look something like:

INFO sip:[email-masked]
To:;tag=12354354
From:;tag=ehrkekd
Call-ID:[email-masked]

Now, I KNOW that this isn't backward compatible, since the HOST part is
currently mandatory in the To- and From URLs. However, that could be
solved by keeping the HOST part of the URLs in every message, but
removing the USER part - or simply to add some "dummy" USER part.

INFO sip:[email-masked]
To:you;tag=12354354
From:me;tag=ehrkekd
Call-ID:[email-masked]

It would save us a few bytes, and it would add a little security since
we won't send all user information in every message.

Just some thoughts...

Regards,

Christer Holmberg
Ericsson Finland