Re: [Sipping] Thoughts on the conf-info package

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

Another old thread. I am in the process of revving both the conf-info 
and conferencing models drafts, so I've been thinking about these 
issues. I wanted to generalize a bit here.

Orit Levin wrote:
> Hi guys!
> I think that Rohan's "thoughts about conferencing" hit a number of
> crucial
> missing points.
> Before arguing about the implementation, I will try to summarize the
> implicitly disputed requirements:
> 
> 1. When a user is invited to a session, which is a part of a conference,
> information MUST be provided to the user informing him that he is a part
> of
> the conference. (The user MAY ignore this information.)
> 2. When a point-to-point session is expanded to a conference,
> information
> MUST be provided to the user informing him that he becomes a part of the
> conference. (The user MAY ignore this information.)

There is a much bigger problem looming here, one which I alluded to at 
the interim meeting. It all ties back to this issue of a URI as a 
service, and what that means.

We have agreed that a conference is a URI, and like other URIs, it 
represents a resource. In this case, the resource is not a user, but a 
service. That service has various ways in which you can interact with it 
- methods you can invoke on it, extensions it supports, event packages 
it can understand, and so on. I think that, generally, it is futile to 
try to actually define a service in any way beyond the externally 
visible behaviors it exhibits. As such, a service is really a collection 
of these methods, extensions, and other characteristics that reflect the 
ways in which you can interact with it.

In SIP, we have two ways to find out about the characteristcs of a 
resource I am in a dialog with. One, is through OPTIONS. That provides a 
"pull", allowing me to ask. The other is that the peer can provide the 
information in an INVITE or re-INVITE, and in that re-INVITE, include an 
updated set of Allow, Accept, Allow-Events, and other headers. That 
supports a "push" model, allowing them to tell me.

So, let us apply this general model to the problem at hand.

When a one-one call "expands" into a conference, what this REALLY means 
is that the resource on one end of the call (identified by the contact 
URI) has changed; its now no longer a "user", but a "service", and is 
therefore something that has an additional set of ways in which you can 
interact with it. In particular, it now supports the conference event 
package, amongst other things.

As such, I would propose that, if a call expands from a 2-way call to a 
conference, the UA would re-INVITE on the original leg, and include in 
the re-INVITE an Allow-Events header with the package conference listed 
there. Indeed, the UA may even change the contact URI, to indicate a 
very explicit change in the nature of the resource. This general 
approach would support other changes that might occur when the call 
turns into a conference. For example, a restriction in the set of 
codecs, which would also be signaled with a re-invite.

THe other obvious external characteristic of the conference is the 
"mixing" characteristic, which is that all dialogs connected to that URI 
will have their media mixed and distributed. I don't know how to 
represent this fact with any existing SIP header. Let us for now assume 
its some new header, Resource-Characteristic, with the value "mix". 
Following the same model, when the two-party call turns into a 
conference, the re-INVITE would include this header. The UA would also 
include the header in a 2xx to OPTIONS.

Note that the mixing characteristic, and the ability to support the 
conference package, are *separate* things. Both are typical of a 
"conference" as we might think of a conference, but it is reasonable to 
allow for devices to be built which only do one, but not the other. So, 
instead of defining that "conferences must support the 
conference-package", I'd rather have a general mechanism whereby a 
resource can express the ability to support the conference package.

This gets around a number of thorny problems, some of which came up in 
this thread. For example, if I'm in a two-party call with another UA, 
and that UA is *capable* of acting as a local mixer, is there a 
"conference" or not? We don't need to decide. In this case, I would be 
able to determine that there are no other users in the conference 
(through a SUBSCRIBE to the conference package), and that the UA can be 
used as a mixer. My UI could present this to me in whatever way it 
chooses. Probably it would indicate that I'm not in a conference, but if 
I clicked "add" to add a party, it would REFER the new user to send an 
INVITE to the UA I'm in the call with.

Hopefully this is making some sense.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP