Subject: [Sipping] Update to conferencing package

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2003 14:11:38 -0400

Folks,

You may have noticed that I submitted an update to the conferencing 
event package. This draft hasnt been touched for a while, since we 
were waiting for the conferencing design team to get farther along. We 
are at the point were it was appropriate to rev the document based on 
the current conferencing story.

You can grab the draft at:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-01.txt
http://www.jdrosen.net/papers/draft-ietf-sipping-conference-package-01.txt
http://www.jdrosen.net/papers/draft-ietf-sipping-conference-package-01.html

Some of the changes in the spec are:

* the XML format has information now that allows you to discover the 
conference policy and media policy protocols. It is done with a new 
<conf-service> element that contains a URI and a service type.

* there are a bunch of new event header parameters that allow you to 
ask for specific subsets of the conference state, such as membership 
status, dialog information, conf-service information, etc. You'll only 
get notified when that subset changes. You can ask for more than one 
subset in a subscription by using a comma separated list of the 
parameters.

* There used to be a bunch of information about who was receiving your 
media. That has all been removed, and will instead be handled by an 
extension to the package to cover the media policy states.

* registered the schema

The open issues are:

* do we really want to learn the URIS for the other conference 
services (media and conference policy control) through a package? The 
information never changes, really.

* the format for the conference service stuff really depends on the 
protocols we select. For example, if xcap is used, you need to include 
an AUID, whereas thats not used for other protocols. As such, its not 
clear we can include conference service information in the XML until 
that work is more solid. If the aim is to have the conferencing 
package proceed in sipping independent of xcon, this could be a problem.

* The media streams information in the notifications indicates which 
media streams the user is connected to. This is also dependent on the 
media policy work in xcon. Its not clear that any media information 
can be present in this package without introducing a dependency on the 
xcon work.

Comments or inputs on these issues are welcome.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    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

---

From: Orit Levin <[email-masked]>
Date: Tue, 8 Jul 2003 15:34:30 -0400

Hi Jonathan!

Some comments:

1. The package doesn't contain information (or a placeholder for potential
information) about conference's side-bars as agreed by the conferencing
design team.

2. May be it is better to define the default subscription lifetime as the
conference lifetime rather than a default of one hour. 

The rest of my comments are inline.

Thanks,
Orit.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2003 2:12 PM
> To: sipping
> Subject: [Sipping] Update to conferencing package
> 
> Folks,
> 
I like the "User Element" concept because it conveys user's "conference
status" vs. dialog status. It is also important to distinguish between a
specific user that has "dialed in" the conference or has been "dialed out"
by the focus.
From the same "conceptual" (i.e. conference vs. dialog) reason as above, I
suggest that the conferencing package will contain only a list of dialog
identifiers allowed to be known/published instead of carrying the dialogs'
information itself. Once a dialog identifier is known, an interested (and
allowed) party can register and retrieve the dialog information using the
dialog package(s) using the dialog package(s) parameters and policies.
Otherwise (from pure technical reason) we will have the burden to define
"what the change of the dialog state means to the change in a conference
state", etc.
> information never changes, really.

This information is compact - therefore, I don't think it is a big issue. Do
we have additional or different means to retrieve this information (if
different from default)?
> package proceed in sipping independent of xcon, this could be a problem.
I agree that we need to provide an array of general "service placeholders"
(a REGISTERED service id and a single pointer or token). Each service can be
defined later by out-of-SIPPING groups. 
> can be present in this package without introducing a dependency on the
In my opinion, no media information should be defined in basic conferencing
package: Any dialog media information should be retrieved using the dialog
package(s). Any conferencing media information (i.e. mixing, switching,
layouts ...) should be defined by MPCP/XCON and its services with their
future corresponding packages.