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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Jun 2002 03:49:45 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jun 2002 14:17:45 -0400

Jonathan,

This is an interesting proposal. I think I like it, but there are some things I don't understand.

There is a question below.

	Paul

Jonathan Rosenberg wrote:
> will have their media mixed and distributed.

What do you mean by "that URI"? Do you mean the Contact URI, or the request URI that was used to establish the call, or what?

This could be a "normal" sip phone that happens to have mixing capabilities. It may also be able to handle independent concurrent calls to the same address. If so, what
happens when one of the calls converts to a conference? Is there some way for another party to call in to that conference without being interpretted as a request for an
independent call? 

I suppose that when the call converts to a conference, a unique conference address could be used in the Contact header. But that would be odd - normally that wouldn't be
used to initiate a new call to that UA. Or it could include a Reply-To header with a conference URL. Maybe somebody could be expected to try that.

> I don't know how to

---

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

> things I don't understand.

Mee too ;)

Inline.

> What do you mean by "that URI"? Do you mean the Contact URI, or the
> request URI that was used to establish the call, or what?

"that URI" is the one that is for the conference.

Let me give an example. A calls B. A's INVITE looks like, in part:

INVITE B
Contact: sip:[email-masked]

B accepts and sends a 200 OK. A then calls C, and then decides to 
conference them both together. It acts as a local mixer. It would send a 
re-INVITE to B:

INVITE B
Contact: sip:[email-masked]
Allow-Events: conf
Resource-Characteristic: mix

The URI for the conference is sip:[email-masked].

> 
> This could be a "normal" sip phone that happens to have mixing
> capabilities. It may also be able to handle independent concurrent calls
> to the same address. If so, what
> happens when one of the calls converts to a conference? Is there some
> way for another party to call in to that conference without being
> interpretted as a request for an
> independent call? 

Sure; it would re-INVITE and change the Contact address ONLY on those 
calls that are now getting mixed together.

> 
> I suppose that when the call converts to a conference, a unique
> conference address could be used in the Contact header. 

Right!

>But that would
> be odd - normally that wouldn't be
> used to initiate a new call to that UA. Or it could include a Reply-To
> header with a conference URL. Maybe somebody could be expected to try
> that.

Well, we've wandered into an old problem that has arisen time and time 
again - how to direct a new call to a UA *instance* rather than a user? 
Its arisen for transfer too. Our current "best practice" for that is to 
address it to the address in the To/From but use caller prefs to target 
an instance. This is frought with problems, and doesn't work generally. 
We need to solve that problem generally, and then use that solution here 
too.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2002 01:39:03 -0400

> an instance. This is frought with problems, and doesn't work generally.

Ugh. I don't see how callerprefs even helps here.

At least in principle, I could have established an arbitrary number of conferences on my phone. Each would require a new ua address (user part). While this is no problem,
it is a problem to have them all registered with A's registrar so that a proxy can use callerprefs to select the proper one. It would be really unpleasant to make up a new
contact address for each established conference, register it, and then remember to unregister it when the conference was over. This seems like a nearly unworkable hack.

> We need to solve that problem generally, and then use that solution here

So I buy that. Until then this doesn't seem like a very useful solution.

	Paul

---

From: Alan Johnston <[email-masked]>
Date: Tue, 25 Jun 2002 17:16:01 -0500

Jonathan,

See my comments below.

Alan.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jonathan Rosenberg
> Sent: Monday, June 24, 2002 3:38 PM
> To: Paul Kyzivat
> Cc: Orit Levin; 'Anders Kristensen'; Rohan Mahy; [email-masked]
> Subject: Re: [Sipping] Thoughts on the conf-info package
> 
> 
> 
> 
> Paul Kyzivat wrote:
> > Jonathan,
> > 
> > This is an interesting proposal. I think I like it, but 
> there are some 
> > things I don't understand.
> 
> Mee too ;)
> 
> Inline.
> 
> >>"mixing" characteristic, which is that all dialogs 
> connected to that  
> >>URI will have their media mixed and distributed.
> > 
> > 

This is essentially A acting as a 3pcc to establish a new session (the
conference) with B.

This is very close to what I was thinking, but I recall Henning talking
at the interim meeting about a conference URI (which is an AOR instead
of a Contact).  It is also very similar to your original join URI passed
around in the "To-Join" header.  If A's URI is sip:[email-masked] then the
conference URI would be sip:[email-masked], which probably
resolves to the Contact sip:[email-masked] which may be A's UA if
it is mixer, or may be A's conference bridge.

Within a dialog, A could make the transition using a re-INVITE and the
change of Contact (and probably SDP) as you show.  However, to add in
the third (or fourth...) party, a conference URI which is an AOR would
be needed.  A could send a REFER to D with the conference URI as the
Refer-To, or it could send the REFER to the conference bridge with the
Refer-To as D, or it could act as a 3pcc and send an INVITE to D using
the bridge SDP and Contact.

Of course, the conference URI must be registered, but I think this is a
small price to pay for the generality you get.

I have some call flows showing this that I plan to include in the next
SIP Service Examples I-D.

> > capabilities. It may also be able to handle independent concurrent 
> > calls to the same address. If so, what happens when one of 
> the calls 
> > converts to a conference? Is there some way for another 
> party to call 
> > in to that conference without being interpretted as a request for an
> > independent call? 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 25 Jun 2002 16:47:46 -0700

Hi,

I don't want to rely on a proxy being able to find now-a-mixer@

On Tuesday, June 25, 2002, at 03:16 PM, Alan Johnston wrote:

> of a Contact).
why does it have to be an AOR?  it could be either.  it should be up to 
A.

> It is also very similar to your original join URI passed

> be needed.
why?  I should be able to handle an arbitrary number of dialogs for a 
Contact URI.  Also I should be able to use one or more conference URIs 
to identify a conference, as long as all of them only refer to that 
single conference.

> A could send a REFER to D with the conference URI as the

> small price to pay for the generality you get.
it may not be possible to register these new AORs.  You should be able 
to do this:

INVITE B
Contact:[email-masked]

reINVITE B
Contact: A;conf=[email-masked]

Also, there is still value in an explicit Join header.  Say I (A) am 
talking to you (B), and i yell to my receptionist to join in the call to 
jot down a date or a phone number.   The receptionist (C) could send an 
INVITE with a Join header to join the call (which isn't a conference 
yet).

So C sends:
    INVITE A
    Join: 42839829;to-tag=09893;from-tag=29445

A responds
    200
    Contact: A;conf=1

A also immediately sends a reINVITE

   INVITE B
   Contact: A;conf=1

hope this makes sense.
thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jun 2002 14:50:12 -0400

> Contact: A;conf=[email-masked]

I think we are all saying the same thing.

The first, and MOST IMPORTANT point to agree upon is that, in all cases, 
a conference is identified by one (or possibly multiple "aliases") URI. 
This applies to any conference that uses a sip star topology, and that 
includes both end-system mixing and centralized dial-in/dial-out 
servers. To learn about the conference state, you subscribe to that URI. 
To join it, you INVITE to that URI. That should be the case no matter 
where the conference is hosted, or how the media is distributed 
(multicast, multi-unicast, mixing). The state of the conference is the 
collection of dialog state associated with that conference. Each URI 
maps uniquely to a conference; a single URI can never reference multiple 
conferences.

Once we agree upon that, we would need to agree that, if an end-system 
turns some number of 1-1 calls into a conference by becoming a mixer, it 
performs a re-invite on those dialogs to change the contact URI to a 
conference URI.

It then comes down to the issue of how one constructs a conference URI 
that is globally routable when the UA is doing the mixing. Alan has 
proposed registering the conference URI. ROhan has proposed using the 
AOR for the host, but with a conference parameter that identifies the 
conference. I think we need to work it through, but this is at a third 
level of detail. Let us first agree on the two previous points.

> A also immediately sends a reINVITE

I like that. What you are saying is that there are several requirements 
related to joining and creation of conferences. These are:

* it MUST be possible to join a conference without knowing that the 
called party is actually a conference

    THis argues for conference= URI

* it MUST be possible for a UA involved in multiple independent calls to 
join them into a single conference

    This is what my re-INVITE approach was for.

* it MUST be possible for a UA to call another UA, and explicitly ask to 
join a call in progress. The call in progress can be identified by an 
explicit dialog ID, or can be wildcarded, so that the request would be 
to join all calls in progress on that UA (other ways to identify the call?)

    This is what the Join header would be for

I should like that these requirements get captured in one of the several 
requirements documents we have going so far.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jun 2002 16:20:01 -0400

This is sounding good! Another comment below.

	Paul

> level of detail. Let us first agree on the two previous points.
... 
> What you are saying is that there are several requirements

An extension to this is: It MUST be possible to invite a new member to a conference without knowing that the called party is actually another conference. (This makes a
joined conference that is not a star topology, unless extra work is done to reorganize it.)

I'm not sure what ought to happen here. The simplest thing is nothing - just leave the double-star configuration. It is perhaps the option of each end of the leg connecting
the two stars to decide whether to merge its star into the other star.