Subject: [Sipping] conf: comments on draft-rosenberg-sipping-conferencing-framework-01

From: "Eric Burger" <[email-masked]>
Date: Mon, 24 Mar 2003 16:43:30 -0500

First off, this is EXCELLENT having a terminology section.  It is really important to harmonize the other documents with a single, consistent terminology!

Section 2, Mixer
"A mixer receives a set of media streams of the same type..."
What about a conference with Audio/Video streams as well as Audio-only streams.  The first sentence seems a bit limiting without any added value.

Section 3.1, 4th & 5th paragraphs
The example URI ("[email-masked]") would seem to contradict the admonition that "a conference URI is never constructed or guessed by a user."  The key point is the conference URI is opaque.  It could mean something, or it could be a license plate.  Requiring meaning is BAD.  Requiring obscuration is also BAD.  Just leave it as opaque to the framework.

Section 4.4
I would offer that the state of the focus is something quite distinct from the conference policy.  Moreover, different actors have different interests and permissions to access these two disparate information items.  Thus I would offer that separate notification services tend to each.  That is, one (package) for the state of the focus and one (package) for the conference policy.

Section 5.1
I am not comfortable saying "the creation of a conference actually constructs several elements."  In reality, the elements described by the framework rarely exist.  Rather, there are virtual implementations.  For example, most policy servers are hard coded into the application logic.  There are not separate policy servers today, and likely into the future.

Section 5.1
Would a better example of deterministic URI generation be algorithmic?  Keeping records of URIs only helps me be unique within me.  It doesn't help me be globally unique.

Section 5.1.1 & 5.1.3
I think it is a key point to mention that the mechanism in the first paragraph of 5.1.1 is identical to 5.1.3.  That is, there is nothing special about IVR.

Section 5.2.1
Is it worth mentioning a stateful application server as a mechanism for running a conference?

Section 5.3
Is it worth mentioning RTCP anonimyzation?

Section 5.4.2 and 5.4.3
I don't really get the difference between these two examples.

Section 5.5
This section creates a whole "What's the difference between CPCP and SIP?" question in my head.

Saying that moderation is handled the same in CPCP and SIP doesn't help.

Note that the mechanism described in the second paragraph of page 21 doesn't make sense to me.  If the session is moderated and someone does an INVITE and the focus rejects the INVITE, how can anyone ever join the conference?  The time-out mechanism in the third paragraph of page 22 helps, but again doesn't really fit in with the what I imagine to be the call flows.

The notification algorithm described on page 22 in the fourth paragraph is hard for me to understand.  If I (the client) request a change, and it is denied, why would I ever expect it to later become approved?  "Pending" to rejected/approved makes sense.

Also, w.r.t. section 5.8.2, I would really hope that CPCP is SIP: I'm really hesitant to have to implement all the same protocol actions with two different protocols "just because."  Let's pick one and run with it.

Section 5.6
This section needs a good, strong case for the sidebar NOT having a distinct conference URI.

*Why* are users in a sidebar NOT in a different dialog?  There is different media, different participants, different features, different notifications, etc.

My reading of the requirements document is that having the same conference URI would violate REQ-1 of section 3.7 of the requirements document.

The mechanism for joining a sidebar is extremely convoluted.  Wouldn't it just be easier to re-INVITE to the sidebar, at a unique URI, instead?

Section 7
I think conferencing is the kind of service that might benefit from a Privacy section, e.g., hidden members etc.

Typos
=====
Section 3, page 9, 5th paragraph
"... As far as its concerned, its a UA just like any other."
"... As far as it's concerned, it's a UA just like any other."
                 ^               ^
[it is = it's; it (possessive) = its]

Section 4.1, 1st paragraph, line 2
"All participants in the conference are connected to it using a SIP dialog."
"All participants in the conference are connected to it by a SIP dialog."
                                                        ^^

Section 5.1.1
sip:[email-masked]
I would offer sip:[email-masked]

Section 5.8
"Obtaining Membership"
"Obtaining Membership Information"
The original section title implies "obtaining membership *in* the conference", e.g., joining the conference, not "obtaining membership *of* the conference", e.g., who is in the conference.
_______________________________________________
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