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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 17:50:34 -0400

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 12:35 PM
To: Jonathan Rosenberg; Mathieu, Marie-Noelle; [email-masked]
Subject: RE: [Sip] RE: [Sipping] Call and call-id

>> >same call-id in the 2 INVITE requests, is this allowed ? 
>> 
>> Well, the current spec would indicate that you shouldn't do this: 
>> 
>> >The callid MUST be a globally unique identifier and MUST NOT be reused
for 
>> >later calls. 
>> 
>> However, I recall some discussion at an IETF that people were using the
same 
>> call-id across different call legs as a local identifier to correlate
those 
>> call legs. With unique From tags and From fields, there really shouldn't
be 
>> a problem, so I think its OK. However, if we are going to allow it, the
spec 
>> should reflect it. Comments? 
>
>If that's the proper way to solve this problem, then let's put that in the 
>spec. But I'm not convinced that this alone will solve all cases,
especially 
>when this correlated information needs to be presented by a call leg
attempting 
>to join (as in the consultative transfer case).

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.

> It only seems to work when the 
>correlating entity initiates all the calls. If there's a reliable way to 
>correlate an incoming call leg with an existing call, I'd love to hear
about 
>it.

http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt

needs updating and adoption though, if we plan to move forward with it. As
you can see, its currently in the morgue.

-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: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jun 2001 08:34:08 +0300

Hi,

Just a couple of small comments.

If we allow this, I guess using From tags has to be a MUST, since the
two (or more) separate INVITE requests may end up at the same physical
node - even if they are sent to different "logical" nodes (UA B and UA
C).

Also, I also think that it shall be clearly written, on a general call
level, that the From tag must be used when nodes map requests to
specific calls. Currently I think the bis only talks about this on a
transaction level.

Regards,

Christer Holmberg
Ericsson Finland