Subject: RE: [Sipping] Thoughts on the conf-info package

From: "Even, Roni" <[email-masked]>
Date: Thu, 20 Jun 2002 17:07:19 +0300

Jonathan,

I think I like the proposal but I am not sure it is all clear to me
1. Can I tell by the URI if this is a resource or a user. I think that you
meant that you can find out if that is a resource or a user is by the
extension it supports for example conference package for a conference
resource. This is good since a simple UA will be in a conference without
knowing.
2. I think that the mixing characteristics needs the conference package in
order to know the relationship between the streams and the participants.

Thanks
Roni Even

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, June 19, 2002 10:50 AM
> To: Orit Levin
> Cc: 'Anders Kristensen'; Rohan Mahy; [email-masked]
> Subject: Re: [Sipping] Thoughts on the conf-info package
> 
> 
> 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
> [email-masked]                 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 [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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Jun 2002 16:40:59 -0400

Even, Roni wrote:
> 1. Can I tell by the URI if this is a resource or a user.

I think you mean "conference or a user". Both are resources identified 
by the URI.

> I think that
> you
> resource. 

Yes.

> This is good since a simple UA will be in a conference without
> knowing.

Well, its TBD what and how we tell users about the mixing aspects. 
Perhaps its a package too. But, packages are about events. THis is more 
of a property of the resource. I can be a mixer without telling people 
who is being mixed.

-Jonathan R.