Subject: [Sipping] conf: comments on draft-levin-sipping-conferencing-requirements-03

From: "Eric Burger" <[email-masked]>
Date: Tue, 25 Mar 2003 11:21:36 -0500

Section 2
"Each dialog can belong to a different SIP session."
             ^^^ "Can", "Does", "May or May Not"?
Pick one.  Explain choice.

"...media sessions are established between the focus and each one of the participants"
I would offer that *signaling* (e.g., SIP) sessions are established between the focus and the participants.  However, I would also offer that it is rare for *media* (e.g., RTP) sessions to be between the focus and the participants.

Section 3.2
I do not understand the explicitly requirements families, "X with default properties" and "X with particular properties."  How about:
REQ-1 Creation of an ad-hoc conference identifier with specified properties.
REQ-2 Creation of a reserved conference identifier with specified properties.
REQ-3 Properties for conference creation may have well-defined (standard) defaults.*

* Do we want to have well-defined defaults?  Why or why not?

Section 3.4.6
REQ-1 has implications for RTP/RTCP which I would suggest get spelt out.  E.g., the mixer MUST anonymize the CSRC text, etc.

Section 3.5.1
REQ-3
What are conference state elements?

REQ-4
Is this requirement that there is a minimal state, or that there is a minimal state report, e.g., the list of public participants (cf. 3.4.6 REQ-1).

Section 3.5.2
REQ-1
Would not the "including" phrase be for non-participants?  Of course conference participants are interested parties.

REQ-5
Again, what is meant by "state" here?  Is it state or reporting?

Section 3.7
REQ-1 highlights why a side bar URI MUST be distinct from the conference URI.  If it was the same, it would not be possible for a non-participant to address the side bar.

REQ-6
Isn't the logical requirement of a conference-unaware user agent be that SIP means MUST be the ONLY *standard* method for side bar operations?  If a conference-unaware user agent knows non-SIP means, it mean, BY DEFINITION, that it *IS* conference-aware.

REQ-7
What is the perceived value of not establishing a distinct side-bar URI?  Also, this contradicts REQ-1.

REQ-8 and REQ-9
What does it mean to be a participant in multiple side-bars?  How would a UAC manage multiple side-bars if they are not multiple SIP dialogs?

Typo
Section 3.5.3, last line
"information, it wants and capable to receive"
"information it wants and capable to receive"
            ^
_______________________________________________
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