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

From: Orit Levin <[email-masked]>
Date: Tue, 22 Apr 2003 10:18:12 -0400

Eric,
Thanks a lot for the detailed review.
I am addressing your notes inline (and in the upcoming SIPPING 00 version of
the draft).

Orit.

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2003 11:22 AM
> To: Sipping (E-mail)
> Subject: [Sipping] conf: comments on draft-levin-sipping-conferencing-
> requirements-03
> 
> Section 2
> "Each dialog can belong to a different SIP session."
>              ^^^ "Can", "Does", "May or May Not"?
> Pick one.  Explain choice.
I tend to remove this vague sentence and say:
"... focus has direct peer-wise relationships with participants by
maintaining a separate SIP dialog with each."
"Dialog" is a technical SIP concept. "Session" is not. 
> 
> "...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.
> 
The full quote goes as following:
"In centralized case, the media sessions are established between the focus
and each one of the participants. In de-centralized (i.e. distributed) case,
the media graph is a (multicast or multi-unicast) mesh among the
participants..."
We prefer not to state any preference for one way or another because, based
on our discussions, both exist and valid.
> 
> 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.*
> 
Your understanding is absolutely correct. I think your wording is better and
will use it in the next version.
> * Do we want to have well-defined defaults?  Why or why not?
> 
Yes, we do want to have this ability as a part of the architecture: one
entity can define profiles or a default, another entity can create a
conference without specifying its parameters. Immediate examples would be
creating conferences by light end devices and by conference-unaware devices.
> 
> 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.
> 
Very good point! What about the following wording:
"The privacy related requirements imply that "anonymizing" operations MUST
be performed on all: the call control, the media control and the media
content when appropriate."
We can't go into the media details in this document - they should be
captured by the media-related drafts.
> 
> Section 3.5.1
> REQ-3
> What are conference state elements?
Conference state elements are "evolving conference state aspects" as
described in the section. For example: "the current speaker". Would changing
"elements" to "aspects" help in understanding the requirement? Other
suggestions?
> 
> 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).
It is the minimal state report. Done: I added "report" for clarification.
From the standardization work perspective - they are the same - only what
goes on the wire is of our interest.
> 
> 
> Section 3.5.2
> REQ-1
> Would not the "including" phrase be for non-participants?  Of course
> conference participants are interested parties.
> 
Done :-) Thanks.
> REQ-5
> Again, what is meant by "state" here?  Is it state or reporting?
> 
Done: "Report".
> 
> 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.
3.7 REQ-1 merely says that a non-participant can participate in a side-bar
using SIP means only. The implementation of this requirement doesn't
necessary require a different URI. The user can potentially be limited to
participate in a side-bar by an ACL maintained (by non-SIP means) in the
focus. I suggest putting the side-bar discussion on hold till a draft
dedicated to side-bars will be available soon (before the IETF meeting).
> 
> 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.
We are entering a slippery ground here :-)
1. A conference-aware participant by definition (in the framework) MUST have
a SIP conference-aware UA (as defined in cc-conferencing).
2. This conference-aware participant MAY use additional non-SIP means in
order to host/participate in a conference, such as for side-bars.
> 
> REQ-7
> What is the perceived value of not establishing a distinct side-bar URI?
> Also, this contradicts REQ-1.
Please, refer to the note for REQ-1 above.
> 
> 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?
One potential application would be participating in a number of IM
discussions all belonging to the same public conference. The simplistic
answer - by non-SIP means. The real answer - in the draft to be published.
> 
> 
> 
> 
> 
> 
> Typo
> Section 3.5.3, last line
> "information, it wants and capable to receive"
> "information it wants and capable to receive"
>             ^
Done.
> _______________________________________________
> 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
_______________________________________________
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