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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 16:51:10 -0500

Consensus at IETF 52 was that we accept the proposal, that is, the 
current definitions and requirements in bis-05 stand. It is possible for 
implementations to be optimized to not use the URLs as call-leg indices, 
and for replaces to be defined without it, as has been pointed out.

There were no dissenters on the list.

This issue is now closed.

-Jonathan R.

Christer Holmberg wrote:

> 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
> 
> 
> 
> 
> Brett Tate wrote:
> 
>>>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.
>>>
>>The proposal sounds fine.
>>
>>_______________________________________________
>>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
>>
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (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: Vijay Gurbani <[email-masked]>
Date: Wed, 19 Dec 2001 16:51:57 -0600

> and for replaces to be defined without it, as has been pointed out.

Jonathan:

Not dissenting, just a clarification...

Let me recap: your proposal was that the dialog be identified with Call-ID, 
To tag and From tag only (drop URIs in the From and To).  Right?

Bis-05 defines a Dialog to include Call-ID, "local address" and "remote
address" where "local address" and "remote address" *include* the URIs.

So, was consensus at IETF 52 to accept the proposal as defined in -05bis
(include URIs) or what you proposed (do not include URIs, only tags)?

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 23:33:12 -0500

Vijay Gurbani wrote:

>>current definitions and requirements in bis-05 stand. It is possible
>>for implementations to be optimized to not use the URLs as call-leg
>>indices, and for replaces to be defined without it, as has been pointed out.
>>
> 
> Jonathan:
> 

Sorry for the confusion; there was discussion about whether or not to 
drop URLs from the definition of dialog, so that a callee could properly 
set the From URL in requests it sent within a dialog. My proposal was to 
NOT make this change.

> address" where "local address" and "remote address" *include* the URIs.

Correct. Consensus was that this definition stands.

-Jonathan R.