Subject: RE: [Sip] bis definition of a call (was [Sip-implementors] Are w e allowed to use same Call-ID ...)

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Nov 2001 10:08:33 -0500

I strongly disagree that the -04 definition was correct, and
will go further to say that there is no value in trying to
provide a concise technical definition. 

If I have a multiple-200 to INVITE scenario and don't do
something to invoke mixing, I end up in more than one "call",
each with independent state and purpose. If a pair of participants
duck out of a conference for a side conversation using some of
the mechanisms Rohan has been kicking around, are they in the
same "call"?

The point is that the term is, at best, extremely context
specific. We've got too many interpretations in popular use
to pick one and change the names of all the others. Lets leave
it loose.

Now, I disagree that -05 doesn't make a distinction in the
definitions between call and dialog (call-leg). A dialog is
a concretely defined thing in -05.

RjS

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Friday, November 16, 2001 8:00 AM
> To: [email-masked]; Radu Ionescu
> Cc: [email-masked]
> Subject: [Sip] bis definition of a call (was [Sip-implementors] Are we
> allowed to use same Call-ID ...)
> 
> 
> I am putting this on the SIP list because it has a bis-05 issue.
> 
> I think the bis-04 definition of a "call" is the correct one. A call
> includes all dialogs in a session invited by a common source, 
> and they would
> have the same Call-ID. Bis-05 should be corrected. Or was 
> there a specific
> reason for changing the definition?
> 
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> [email-masked]
> 
> ----- Original Message -----
> From: "Radu Ionescu" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, November 15, 2001 3:35 PM
> Subject: [Sip-implementors] Are we allowed to use same 
> Call-ID for multiple
> dialogs for the purpose of a non based MCU multiparty conference?
> 
> 
> >
> >
> > Bis05 does not seem to make any difference between Call and CallLeg
> >
> > Call: A call is an informal term that refers to a dialog 
> between peers,
> > generally set up for the purposes of a multimedia conversation.
> >
> > Call leg: Another name for a dialog.
> >
> > Dialog: A dialog is a peer-to-peer SIP relationship between 
> a Various
> > Authors [Page 13]  Internet Draft SIP October 26, 2001 UAC 
> and UAS that
> > persists for some time. A dialog is established by SIP 
> messages, such as
> > a 2xx response to an INVITE request. A dialog is identified 
> by a call
> > identifier, local address, and remote address. A dialog was formerly
> > known as a call leg in RFC 2543.
> >
> >
> >
> > However in Bis04
> >
> > Call: A call consists of all participants in a session invited by a
> > common source. A SIP call is identified by a globally unique call-id
> > (Section 10.12), and is created when a user agent sends an INVITE
> > request. This INVITE request may generate multiple 
> acceptances, each of
> > which are part of the same call (but different call legs). 
> Furthermore,
> > if a user is invited to the same multicast session by 
> several people,
> > each of these invitations will be a unique call. In a multiparty
> > conference unit (MCU) based call-in conference, each 
> participant uses a
> > separate call to invite himself to the MCU.
> >
> > Call leg: A call leg is a pairwise signaling relationship 
> between two
> > SIP user agents. A call leg is established when a call invitation
> > results in a successful response. It is identified by the 
> combination of
> > the Call-ID header field, the local address of the 
> participant, and the
> > remote address of the other participant. For the caller, the local
> > address is the From field of the INVITE, and the remote 
> address is the
> > To field of the 200 class response. For the callee, the 
> local address is
> > the To field of the 200 class response to the INVITE, and the remote
> > address is the From field of the INVITE. SIP URIs are 
> compared according
> > to Section 2.1, non-SIP URIs according to Section 2.2. 
> Within the same
> > Call-ID, requests with From A and To value B belong to the 
> same call leg
> > as the requests in the opposite direction, i.e., From B and To A.
> >
> >
> >
> >
> > My question - are we allowed to use same Call-ID for 
> multiple dialogs
> > for the purpose of a non based MCU multiparty conference?
> >
> > Thank you,
> > Radu
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [email-masked]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> 
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Nov 2001 00:12:41 -0500

> From: Radu Ionescu [mailto:[email-masked]]
> Sent: Friday, November 16, 2001 6:08 PM
> To: Robert Sparks; Bob Penfield
> Cc: [email-masked]
> Subject: RE: [Sip] bis definition of a call (was 
> [Sip-implementors] Are
> we allowed to use same Call-ID ...)
> 
> 
> I agree that dialog is concretely defined thing in -05. But Call and
> Call Leg are loosely defined in -05. 
> 
> The question was specific for the purpose of mixing - yes it is
> extreemely context specific (this question is out of context without
> doing something to invoke mixing). Can RFC be more specific on this
> issue since I expect to see a lot of people doing mixing? 

Bis is quite clear that for each dialog, the call-id is unique. THus, for a
centralized mixer, which involves multiple dialogs, each has a separate
call-id. They are correlated with the request URI (see
http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-models-0
0.txt). We have toyed with reusing call-id in the past, and always end up in
trouble since there are so many possible interpretations of what this means.
Now, the definition is concise and provides some useful properties (unique
identifiers are always useful).

-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