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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Apr 2003 10:59:57 -0400

My apologies for the delay in responding. Thanks for your comments.
Responses inline.

Eric Burger wrote:

> 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.

THe idea is that a conference would just have multiple mixers if there 
were multiple media types. Its really just a matter of definition about 
whether a mixer is single or multiple media. Some folks on the design 
team felt strongly that it should be a single media per mixer.

> 
> 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.

Having a URI with a mnemonic user part does not mean its no longer 
opaque to the system, no longer unique, or that the intent is for it to 
be guessed. For long lived conferences in particular, where there is a 
likelihood that someone will need to convey one over a phone, I see 
value in them being mnemonic.

> 
> 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.

The design team has debated this issue heavily. At the time of the 
writing of the framework, we hadnt really decided, and so the wording 
was made vague so as to allow the decision to be made later. Since then, 
we have agreed on an approach. The idea is to have a single package, but 
to use an event parameter to indicate whether or not you would want only 
the focus state or the policy state. A single package avoids the waste 
of managing two subscriptions in the common case of endpoints that want 
both. Here is the updated text to clarify:

This state is composed of two separate pieces. The first is the
state of the focus and the second is the conference policy. A
subscriber to the conference notification service can use capabilities
defined in the SIP events framework \citenonnorm{rfc3265} to request
that it receive focus state changes only, conference policy changes
only, or both.

> 
> 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.

The text is not saying that a policy SERVER is constructed, its saying 
that an instance of the conference policy and focus are created. In a 
real implementation, this would manifest itself as the addition of a row 
in a table or something.

I clarified the definitions of conference and media policy to make it 
clear that these were per-conference.

> 
> 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.

Unique within you is OK if you are unique, since the URI includes the 
domain part. I'll mention that algorithmic is another choice - i.e., 
some kind of GUID generator.

> 
> 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.

You are right. In fact, the first paragraph of 5.1.1 doesnt belong 
there, since the mechanism is not automated. It belongs rather in 5.1.3 
which describes non-automated mechanisms.

I've changed the first paragraph in 5.1.1 to read:

SIP can be used to create conferences hosted in a central server by
sending an INVITE to a conferencing application that would
automatically create a new conference and then place a user into it.

and the first paragraph in 5.1.3 is now:

One way to create a conference is through interaction with an IVR
application. The user would send a SIP INVITE to the conferencing
application. This application would interact with the user, collect
information about the desired conference, and create it. The user can
then be placed into their newly created conference.

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

I don't understand. 5.2.1 is talking about adding users to a conference. 
What does that have to do with using an application server?

> 
> Section 5.3 Is it worth mentioning RTCP anonimyzation?

The section doesn't give any details on what the conference server needs 
to do in order to provide anonymity. It merely discusses how a user 
would ask for anonymity before joining. SO, I dont see the need here.

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

One of them uses CPCP to remove a user. This can be done by an automata. 
The other uses a web application to remove a user. THis can only be done 
by a user.

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

These are totally difference protocols, so I dont see the confusion.

CPCP will allow you to do things like say "when Eric joins the 
conference, he will be granted permission to eject other users", or 
"eject bob from the conference" or "create a new conference with bill as 
the moderator". How can any of these be done with sip? CPCP is a basic 
data transaction protocol.

The only intersection with SIP is that both change the state of the 
conference in some way. As a result, since state changes can be 
moderated, SIP invitations or CPCP actions may need to be moderated. I 
think its reasonable that the basic moderation mechanisms should not 
depend on how the state change request was made. Thats all this section 
is saying.

So, just because both SIP and CPCP can change the state of a conference, 
does not mean that they are the same protocol.

> 
> 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? 

Yeah, good point. I'll remove that bit and leave the part that says you 
get put on hold.

> 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.

OK - what did you have in mind?

> 
> 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.

Yeah, I see why this is confusing. The right way to say this is that the 
CPCP transaction completes, with a response of "will be done pending 
authorization". THus, later, it is either approved or rejected. I'll 
change the wording.

> 
> 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.

See above discussion on why these are just not the same. In the case of 
conference participants, you will basically learn them as the result of 
a full-state update generated by a subscription to the conference state. 
  CPCP, being a data transaction protocol, would also allow you to 
directly query for the list. Just because there is this sliver of 
overlap does not mean that they are the same protocol.

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

I'm confused - are you saying it should have the same URI? Sidebars do 
have a separate URI.

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

The problem was that this would require endpoint mixing to work. What 
you want is that the user in the conference have their one dialog to the 
server, and if they join a sidebar, the media they receive on that 
dialog changes to reflect their presence in the sidebar.

I personally really wanted to have it be a truly separate conferenece, 
separate dialog, etc., but the complexity of doing this was extremely 
high. So, the text you see now is a middle ground position - to try and 
keep them separate to the greatest degree possible without imposing 
undue burdens on the endpoints.

> 
> 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.

Right - but its not.

> 
> 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?

There is no way in SIP to re-INVITE to a different URI.

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

Good point. I added:

Privacy is an important aspect of conferencing. Users may wish to join
a conference without anyone knowing that they have joined, in order to
silently listen in. In other applications, a participant may wish just
to hide their identity from other participants, but otherwise let them
know of their presence. These functions need to be provided by the
conferencing system.

> 
> 
> 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]

I frequently make this mistake. Fixed.

> 
> 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." ^^

Fixed.

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

Fixed all non example.com or example.net domain references.

> 
> 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. 

Fixed.

Thanks for your comments!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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