Subject: Call-id in INVITE messages with ALSO and REQUEST-BY

From: Wing Man Kwok <[email-masked]>
Date: Wed, 22 Sep 1999 15:27:43 -0400

All,

I have a question about the call-id values in INVITE messages with ALSO or
REQUEST-BY headers as specified in draft-ietf-mmusic-sip-cc-01.txt.

Suppose we have the following scenerio:

A is talking to B in a call with call-id [email-masked]
Now A wants to add C to the call (thus it becomes a conference call).  The
following INVITE messages will be exchanged:
   A sends C an "INVITE C  Also:B"
   C sends B an "INVITE B  Also:A  ReqBy:A"

My question is:
   Are the above two INVITE messages sent with the call-id [email-masked] of the
ongoing call between A and B?  

Thanks.

Wing Man Kwok

---

From: Jeff Mark <[email-masked]>
Date: Wed, 22 Sep 1999 14:29:25 -0700

Yep, that's right.  You would use the call-id ([email-masked]) of the existing
A-B call. When B receives the triggered INVITE from C it will know C is
being added to the exisiting call ([email-masked]).  If a different call-id was
used, B would think this was a new call being formed.

There is an add party example in the draft (Figure 3 in section 8) where A
& B were connected, and A was adding C to the call.  Let's use your
call-id of [email-masked] for the exising A-B call.  Adding the call-id to the
diagram we get something like this for the message flow:

	A->C: INVITE C
	      Call-Id: [email-masked]
	      Also: B

	C->B: INVITE B
	      Call-Id: [email-masked]
	      Also: C            <---- Why C?
		Requested-By: A

	B->C: 200 OK
	C->B: ACK

	C->A: 200 OK
	A->C: ACK

In the C->B triggered INVITE the draft indicates an "Also: C" would be
included.  C is the one sending the message so why would it include itself
in the INVITE message?  I don't think having "Also: A" as your flow
suggests is really needed either.  I think the draft says somewhere that
the participants in the Also header are those that the endpoint is already
connected with.  For this particular case it would be sufficient (I think)
to have nobody listed in the Also header of the C->B triggered INVITE.

-Jeff

--
Jeff Mark
Dialogic, an Intel Company

> -----Original Message-----
> From: Wing Man Kwok
>
> All,
>

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 23 Sep 1999 12:07:07 +0100

> to have nobody listed in the Also header of the C->B triggered INVITE.

I think you're right that the draft is not completely clear on what the
value of the Also header of the C->B triggered INVITE should be. 
Section 6.2.1 says:

   "The UA also formulates an internal participant list. This list
   contains a set of URIs for each user, and for each, a version and
   status parameter. This list is initialized to the set contained in
   the Also header in the INVITE. This list is also placed into the Also
   headers of each triggered INVITE."

So according to this, in the example, C should initialize its internal
participants list to consist of B (the value of Also in the A->C
INVITE), and should send INVITE B ALSO B to B, whereas the example says
"Also C".  

At a first glance it would appear pointless for C to tell B to INVITE
either C or B as they are the two parties involved in that particular
triggered INVITE, but one could probably think up race condition
scenarios where B really needs the *associated* information, status and
version parameters, e.g. if B is leaving just as A is adding C, B's
response to the C->B INVITE might depend on whether A added C knowing of
B's departure or not.

It's kind of hard to get a complete picture of all possible race
conditions of that sort so I think maybe the best approach is to be
conservative and specify that C sends *all* available information in the
C->B triggered INVITE, which would be Also: A,B,C.  B then has to be a
bit careful and not send C or itself a triggered INVITE as that could
get nasty!

Regards,
Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Sep 1999 10:43:12 -0400

> response to the C->B INVITE might depend on whether A added C knowing of

You are right that its not clear or consistent from the draft; this is
definitely work in progress and there are many issues to be resolved.
Regarding this one, I agree with Anders in that the associated
information is probably needed, and that the safest thing to do is
include both in the Also. I think we will also need to place the user
who sent the untriggered INVITE (A in this case) in the Also header as
well, as Anders suggests. I'm not entirely sure since the details of the
"version" field are still elusive...

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen