Subject: [Sipping] comments on draft-ietf-sipping-cc-framework-00.txt

From: "Even, Roni" <[email-masked]>
Date: Tue, 5 Mar 2002 14:10:44 +0200

Hi,

I read the draft and I think it is a good idea to put a framework document
for multiparty. I have a couple of comments

1. The document include a reference to a conferencing bridge and to a mixer.
I think that the terms should be clear. My understanding of a mixer as
defined in RTP (see 4.5.1.1) is that it handles only the media streams and
is not dependent on a signalling protocol. I think that the decomposed
approach of a conference bridge that is build from controller and media
processor (mixer) may be used. In section 4.3.2 it says "In a centralized
mixing model, all participants have a pairwise SIP and media relationship
with the mixer."  a mixer does not have SIP relationship. Same in 4.4 "For
example, a mixer involved in a conversation space may wish to provide URLs
for conference status, and/or conference/floor control. "
2. In section 4.3.2.2 "Once the server is discovered, a conference ID is
chosen. This ID must be globally unique." I think that we need to specify
how this is done. Does the server select the ID for the ad-hoc conference.
If the user defines it, we need to specify how to inform that the conference
ID is not unique.
3. Section 4.4 presents the topic of conveying Information and Events based
on draft-rosenberg-sip-call-package-00.txt. How do you see the relationship
between the documents, does this document present requirements for the
draft-rosenberg-sip-call-package-00.txt document. I think that this is a
question about the way we address other requirements that are related to
other documents.  I have some specific events that make sense in a
conferencing environment. For example in audio conference to notify who is
the loudest speaker currently (enabling an application that will present it
to the participants) In video conference the requirement is to know who is
being seen by the others.
4. In 4.5.1.1 "For example, the default combining for an audio conference
would be an N-1 configuration. In other words, each user receives a mixed
media stream that represents the combined audio of all the users except
himself or herself. " This statement may be true for a small conference. In
large conferences the policy is to mix M loudest speakers out of the N
participants (M is typically 3).
Thanks
Roni Even

***********************
Roni Even

Polycom Network Systems
Tel: +972-3-9251200
Mobile: +972-55-481099
Fax: +972-3-9211571
Email: [email-masked]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 11 Mar 2002 10:12:23 -0800 (Pacific Standard Time)

Hi Roni,

Thanks for your comments.  A few replies inline...

thanks,
-rohan

On Mon, 11 Mar 2002, Even, Roni wrote:
> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 2:11 PM
> To: [email-masked]
> Subject: [Sipping] comments on draft-ietf-sipping-cc-framework-00.txt
>
>
> Hi,
>

OK, I meant to define the characteristics of the un-decomposed conference
bridge.  I agree that you can decompose this into a mixer and a
controller.  I think it is a good idea to add this to the draft, but I
need a good name that is not overloaded for the larger thing.  Perhaps:
"SIP mixing service"?

> If the user defines it, we need to specify how to inform that the conference

sounds reasonable

> being seen by the others.

are all of these events described in the levin draft?  If not, we need to
get a list of these.  I think we may need to partition some of these
events into multiple packages, as the current speaker and who is being
seen will likely change much more often than which participants are
represented.

> participants (M is typically 3).

of course, or mix the last, loundest, and longest speakers...   I'll add
some text to that effect.

thanks,
-rohan