Subject: Multiparty Calls

From: "David Shrader" <[email-masked]>
Date: Thu, 04 Nov 1999 22:47:17 -0500

I've been reviewing the proposals in the call control services I-D about the
use of SIP for multiparty calling scenarios. I think the requirements
descriptions for the various types of calls are really good. I'm having
difficulty with the proposed implementation of those requirements using SIP.

I think I can make the method proposed for handling the multiparty calling
work when the streams are being mixed and managed directly by the endpoint.
It appears that the protocol allows any multiparty call scenario to
stabilize after a short time and that the distributed method works. However,
the models that involve a server cause me some difficulty. There appears to
a window in which the an endpoint cannot determine exactly what is being
received on a given media stream, so it cannot properly handle it. For
example, if A is talking with B; A sets up another call with C; Then A
bridges them all together. The distributed approach leads to a mesh of media
streams between A, B, and C. Each recipient has enough knowledge to know
that the appropriate action is to mix the two input streams for playback to
the user.

If one of the parties invites a server to perform the bridging and then all
parties invite the server, the text indicates that a two stage process is
performed. A connection is not replaced until you are sure the user's input
is being mixed through the server. As a result, it looks like there is a
window in which a recipient could be receiving both an input stream from a
conference server that contains A's voice and the recipient could be
receiving a direct stream containing A's voice. The mixing of that could
cause problems and may not produce correct results.

I don't know if there is a solution to this, but maybe there needs to be
some text added to the requirements related to the impact on the recipient's
interpretation of received input streams.

Any thoughts on this topic?
David

----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 05 Nov 1999 07:23:27 -0500

Since you definitely want "make-before-break", it's probably hard to
avoid the problem. However, there is a solution, as long as the mixer
uses RTP: If the mixer includes the SSRC of the sources mixed in the
CSRC list of the RTP header, the recipient can tell that it is getting a
certain party twice.