Subject: RE: [Sip] RE: [Sipping] Call and call-id

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Jun 2001 15:54:28 -0400

-----Original Message-----
From: Chris Hogg [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 6:03 AM
To: 'Jonathan Rosenberg'; 'Zmolek, Andrew (Andrew)'; Mathieu, Marie-Noelle;
[email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

Hi Jonathan, 
Jonathan Rosenberg wrote: 
>>Careful; I am not proposing that two call legs with the same Call-ID
convey 
>>any semantics. Specifically, receiving an INVITE from A, while in a call 
>>with B, where the call-id in the INVITE from A equals the call-id in the
leg 
>>with B, does NOT imply that this is a consultative transfer. For that, we 
>>have Replaces, which lists the replaced leg explicitly. 
>>All I am saying is that a Call-ID may be reused for local convenience, if 
>>desired, but that it has NO semantics outside of the entity that selected 
>>that call-id. 
>Given, what you are proposing will this not mean that the definition of a
call 
>needs to be altered?  The reason I ask is that bis-03 defines a call as 
>"identified by a globally unique callID" and "all participants invited by a

>common source".  In the case you describe under the current definition of a

>call this would mean that we would have two calls (under the "all
participants 
>invited by a common source" rule) but with the same callID (hence
contravening 
>the "globally unique callID" part).    

Well, there are a lot of issues, and this is just one. Thinking about this
more, I think its going to be a slippery slope to change what we've had
specified till now, which is that the call-id is globally unique. So, I'm
not so sure anymore that this reuse is a good idea. Unfortunately, there are
some cases where people are reusing call-id in order to perform some kind of
correlations. I think that will ultimately result in inconsistent behaviors
and unusual errors. SIPs "identifier" computations - call legs, calls,
transactions - are already complex enough. Lets not muddy those waters with
further inconsistencies.

So, I would rather say lets be explicit. Call-ID retains its current
definition. It identifies a call, which is, as the current definition
states, the set of participants invited to a session by a common source. We
will need to more formally define that, but I think the basic meaning is
clear. Now, some of the things people are doing that break this are:

1. As Gonzalo indicated, overlap reuses call-id. I think thats not such a
good idea. Lets be explicit. If they need some extra header to correlate
those things, so be it.

2. For a while, we were using the call-id to provide a way to indicate, for
attended transfer, that the incoming call replaced the existing call. I
think there is consensus not to do this, and to rather use Replaces, which
makes it explicit. Thats good.

3. I think some people might be reusing call-ids as conference identifiers.
That should stop as well. draft-rosenberg-sip-conferencing-models has
defined more appropriate mecahnisms for conference 

Comments? 

-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: "Bob Penfield" <[email-masked]>
Date: Fri, 29 Jun 2001 17:47:49 -0400

> good idea. Lets be explicit. If they need some extra header to correlate

I think overlap's reuse of call-id meets the "set of participants invited to
a session by a common source" definition since the originating gateway is
the "common source". Or does "set of participants invited" mean only those
endpoints that received a singular initial invite that was forked?