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

From: "Eric Burger" <[email-masked]>
Date: Wed, 19 Jun 2002 03:11:48 -0400

Hmmm.

Here is where we could be better than the PSTN.  Yes, if your wife picks up
an extension in your house, no one knows.  However, remember that she is
picking up on the same line appearance.  You know you have multiple
telephone sets on the line.  You know that if you are on the line, others at
other telephone sets can pick-up.

Some key systems have a "private" button on the telephone set that blocks
others from picking that line.  I'm not proposing the "private button"
feature.  Rather, I'm pointing out that people pay to either keep a
particular conversation private or desire to know who is on.

The argument that you could always defeat the system is quite true.  For
example, I always wondered why voice mail systems let you mark a message
"private".  After all, the recipient could always play the message on a
speaker phone or record the message.  However, it is a popular feature
because it deters the amateurs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
David R. Oran
Sent: Thursday, May 23, 2002 11:42 AM
To: [email-masked]
Subject: Re: [Sipping] Thoughts on the conf-info package

--On Thursday, May 23, 2002 11:27 AM -0400 Michael Hammer
<[email-masked]> wrote:

> Rohan,
>
> The notifications below protect the privacy of the person being
> conferenced in.  What about the privacy of the person in the original
> 2-party call?  In some countries, this could be considered an illegal
> wiretap if the mixing party does not disclose the addition of the third
> party to the original party.
>
So be it. It is completely and utterly fruitless to try to fix this with
technical machinery. What about when my wife picks up an extnsion line in
the house? What about holding up a second phone to the first while I dial
someone? Sue me.

> In such legal domains, would the mixer automatically be require to assume
> the implicit subscription and send the notifies?  This is not required
> for every 2-party call, just when a mixing operation is done.
>
Is it legal to send the notifies under an encryption key for which you
don't provide the decription key? Do I have to abort the conference leg if
you don't ACK the notify. Get real.

> Does there need to be a mechanism by which party A can notify the party B
> in a 2-party call that no other parties are authorized to join?  Or
> should that be implicit?
>
Define "authorized". By whom? How? Seems like it is up to party B to try to
ascertain whether anyone has joined, not party A's responsibility to
enforce the property. He may not even be able to if the call runs through a
B2BUA, an anonymizer, or other media transformation engine not under his
direct control (like a transcoder).

> I don't think this necessarily ruins the idea of an anonymous party.  In
> such cases as anonymous auctions, participants may be willing to join the
> conference knowing that all parties identities are not revealed.
> Likewise, for some types of business transactions, the caller may accept
> if notified that others may be listening in, say for quality control
> purposes.  At least if they object they can always hang up.
>
I think you have to assume there are lurkers unless you can enforce that
there are not via cryptographic means. Trying to use the event machinery
for such purposes is misguided and ultimately fruitless.

Dave.

> Mike
>
>
> At 06:58 PM 5/21/2002 -0700, Rohan Mahy wrote:
>
>> Hi,
>>
>> Below are some of my thoughts on the conf-info package and conferencing
>> in general.....
>>
>> <shameless-diatribe>
>>
>> ** Discovering when the conf-info package is relevant
>>
>> Imagine that I want to provide a roster of participants in adhoc
>> conferences as well as dial-in/dial-out conferences.  Many small adhoc
>> conferences (ex: 3-way calls) occur as a result of local mixing.    The
>> diagram below shows B performing local mixing between A, B, and C.  B
>> knows the complete list of participants in the conference, and can render
>> this roster locally, but A and C do not know about each other through
>> SIP.
>>
>>         A   C
>>          \ /
>>           B
>>
>> A could subscribe to the conf-info package at B to find out about the
>> other participants involved in this small conference.  B would verify
>> that A is the same A that was involved in this dialog, and if this was an
>> ordinary conference, return the list of other participants: B and C.
>>
>> How does A know to subscribe to this package?  The dialog between A and B
>> started out as an ordinary 2-party call.  It would be patently ridiculous
>> to subscribe to the conference info package for every two way call, so B
>> should provide some clue to A that more information is available.  A
>> short flow proposing this mechanism is below, where B REFERs A to
>> SUBSCRIBE to the conference-info package (at B), and B informs C that it
>> is joining a conference by including
>> <sip:B;method=SUBSCRIBE?Event=conf-info> in a Call-Info header.
>>
>>     A               B              C
>>
>>     |  stable call  |              |
>>     | <=============>|              |INVITE contains
>>     |               | -INV/200/ACK->|Call-Info header
>>     |               |              |
>>     | <=============>X<============>| start mixing
>>    *|<--REFER/202---|              |
>>     | ---SUB/200---->|<---SUB/200---|
>>     | <--NOT/200-----|----NOT/200-->|
>>     | participants: | participants:|
>>     |   B, C        |  B, A        |
>>     |               |              |
>>
>>
>>    * Refer-To: <sip:B;method=SUBSCRIBE?Event=conf-info>
>>
>> The rule for using these two mechanisms is simple.  If I know that I am
>> inviting someone to a conference and I want to reveal that information, I
>> include a Call-Info header which references a subscription to that
>> information.  If a dialog suddenly becomes involved in a conference and I
>> want to reveal that information, I REFER my peer to SUBSCRIBE to that
>> information.
>>
>> Why is the Call-Info header relevant?  (There was previously some
>> discussion on the SIP list about the abuse of Call-Info carrying a SIP
>> URI for providing identity information).  Call-Info provides relevant yet
>> optional information about one side of a SIP dialog.  This seems like a
>> perfect description of the event package URI.  Certainly if this same
>> information (roster of participants) was provided as an http: URL nobody
>> would complain about this.
>>
>>
>> ** How to authorize providing participant information
>>
>> Lets assume that participants can have an (optional) attribute indicating
>> if they are "hidden" or "visible".  Lets assume that users assume the
>> default attributes unless they explicitly or implictly request otherwise.
>> A user who wants to remain hidden can also use a new Privacy attribute to
>> request that they are hidden from the participant list.  Of course, local
>> authorization policy could cause hidden participants to be seen by some
>> users (for example a moderator) despite this request.
>>
>>
>> ** Using the conference-info package on cascaded conferences.
>>
>> At the interim there was some discussion about adding a parameter to the
>> conference-info package to indicate that the subscriber wanted their
>> subscription to recurse through cascaded conferences.   Some folks
>> thought that it might be too hard to deal with the authorization issues
>> in such an environment.  I want to explain both the motivation for this
>> feature and why I think the feature is moderately easy to implement.
>> Two types of cascaded conferences are shown below:
>>
>>                      +-----+   +-----+
>>    A     C           |mixer|---|mixer|
>>     \   / \          +-----+   +-----+
>>      \ /   \          | | |     | | |
>>       B     D         A B C     D E F
>>
>>
>> Adam Roach suggested that if you were interested in the complete
>> partipant list of a cascaded conference, that you could issue several
>> subscriptions. This is overkill and a waste of resources as I will show
>> below.
>>
>> Consider the topology described below:
>>
>>
>>     +-------------+       +-------------+
>>     |     M1      |       |     M2      |
>>     |             | -------|             |
>>     |             |       |             |
>>     +-------------+       +-------------+
>>      |  |  |  |  |         |  |  |  |  |
>>      |  |  |  |  |         |  |  |  |  |
>>      |  |  |  |  |         |  |  |  |  |
>>      A  B  C  D  E         F  G  H  I  J
>>     /             \               \
>>    /               \               \
>>   X                 Y               Z
>>
>>
>> M1, M2, A, E, and H are all mixers in this example.
>>
>> If each UA involved in the conference wanted to get an accurate list of
>> participants, you would end up with 105 subscriptions.  This is a classic
>> n-squared scaling problem (n=15, 15 * 14 / 2 = 105).  If recursion is
>> available automatically, only 18 subscriptions are necessary.  Just as in
>> the 2-party call case, it is not necessary for M1 to subscribe the
>> conf-info package at B, C, or D.  M2 doesn't need to subscribe to F, G,
>> I, or J.  Nor does A subscribe to X, E to Y, or H to Z.  (Each arrow in
>> the diagram below shows a subscription)
>>
>>
>>
>>     +-------------+       +-------------+
>>     |     M1      |       |     M2      |
>>     |             | <----->|             |
>>     |             |       |             |
>>     +-------------+       +-------------+
>>      ^  ^  ^  ^  ^         ^  ^  ^  ^  ^
>>      |  |  |  |  |         |  |  |  |  |
>>      v  |  |  |  v         |  |  v  |  |
>>      A  B  C  D  E         F  G  H  I  J
>>      ^           ^               ^
>>      |           |               |
>>      X           Y               Z
>>
>>
>> The main criticism of recursion is that authorization filtering as you go
>> from mixer to mixer is difficult.  Fortunately the authorization burden
>> of generating a conf-info document only falls on entities which are
>> mixers [or who wish to assert special attributes about their
>> participation (robot, passive, or hidden).  Note that being hidden is
>> different from merely being a visible participant who happens to be
>> anonymous.]
>>
>> If M1 has appropriate moderator priviledges on M2, then M2 will include
>> the hidden participants that it is aware of to M2 (perhaps M1 and M2 are
>> operated by the same large company).  If M1 does not have appropriate
>> moderator priviledges on M2, then M2 will only provide a list of visible
>> participants.  Likewise, a mixer could use local policy to withhold
>> participant information implictly (the announcement robot participant
>> built into the system may be hidden implicitly, or H (a tech support call
>> center agent) may implicitly hide Z (the agent's supervisor who is
>> silently monitoring H's participation).
>>
>> M2 may choose to use authentication information to gather more
>> information about the participants.  It might pass this information
>> along unless appropriate Privacy is requested.
>>
>> </shameless-diatribe>
>>
>> All this seems like reasonable mechanism and not too difficult to
>> implement to me.  Comments and flames welcome on this topic.
>>
>> Also, re:
>>
>> **  subscribing to conference creation and deletion
>>
>> A UA in a network management, monitoring, or scheduling capacity, may be
>> interested only in a list of conferences on a particular conference
>> server, as opposed to complete participant information for a conference.
>> Should we solve this requirement using the same conf-info package using a
>> "filter" during the SUBSCRIBE, or a new event package, or not at all?
>>
>> thanks,
>> -rohan
>>
>>
>>
>> _______________________________________________
>> 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

-----------------------------------------------------------
David R. Oran                   Phone/Fax: +1 978 264 2048
Cisco Systems                   VoIP: +1 408 571 4576
7 Ladyslipper Lane              Email: [email-masked]
Acton, MA 01720

_______________________________________________
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: "Eric Burger" <[email-masked]>
Date: Wed, 19 Jun 2002 03:11:59 -0400

In any scheme controlled by the endpoints, we have to assume the endpoints
are evil and won't do what you want them to do, unless there is some
cryptographic way of ensuring it.

For example, we could solve this issue by having an authoritative entity
(trusted proxy, e.g., or I trust you to be good) that lists participants,
rather than you just trusting my phone (which I program) to tell you (or
not) who is (or is not) on the call.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Rohan Mahy
Sent: Thursday, May 23, 2002 2:03 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [Sipping] Thoughts on the conf-info package

Hi,

> Rohan,
[snip]
> in a 2-party call that no other parties are authorized to join?  Or should
> that be implicit?

it seems useful to have an explicit way to request that.  Perhaps an new
Privacy token would solve this problem ( no-conf )?

> conference knowing that all parties identities are not revealed.
Likewise,
> for some types of business transactions, the caller may accept if notified
> that others may be listening in, say for quality control purposes.  At
> least if they object they can always hang up.

I agree.

---

From: Orit Levin <[email-masked]>
Date: Thu, 20 Jun 2002 13:03:21 -0400

I completely agree that "mixing" issues and conferencing issues are separate
things. For example, you may have a SIP centralized Conference without
centralized "mixing" at all (i.e. Star Signaling with mesh Media.)

Additionally, I think that UA's "conferencing mixing capabilities" and a
specific conference "mixing characteristics" are different things. First may
be resolved by OPTIONS, the second by a media part of the Conferencing
Package or (preferably) by a separate package (to keep the separation
clear).

Keeping the separation in mind, I suggest that we define a solution to the
SIP conferencing requirements (without the mixing aspect) first.

I have two open issues with the proposed approach:

1. Following the same path as above, UA's support for Conferencing (i.e.
Conferencing Package) is different from a SIP dialog being a part of a
specific Conference. The first one can be naturally signaled within the
Allowed-Events header. The second one requires a "Conference Identifier" and
must "belong" to a dialog. Does the Allow-Events header allow for such token
definitions?

2. According to the "Conferencing Models" draft, the Conference existence is
signaled by a Conference "Service URI" within a Request URI (in the Dial-in
case) and within a "from" (in the Dial-out case).
- First, "by definition", this approach requires a "Conferencing Service" be
defined and identified. That is different from the spirit of the latest
proposal.
- Secondly, the resulted SIP dialogs in the add-hoc scenario and in the
dial-in/dial-out scenarios would look completely different.

May be, it would be simpler to look at the "Conferencing attributes of a SIP
dialog" as an add-on service above a SIP dialog for both cases. By doing
this, we will be able to address both in the same way.

We may define a new optional "Service Header" with clear semantics to
contain a Service ID (i.e. URL), Event Package URL, etc. The Conferencing
Server would include the header for all dialogs belonging to a Conference. A
Conference Participant MAY ignore it. Still, in the Dial-in case, the
Participant MAY put the Service URL inside the Request-URI (if it knows its
value). If the Participant supports the Service Header, it would insert the
Conference ID (URI) for a known Conference or a "Conference Service
Description" to request a new conference.

I guess, we first need to decide whether we want to combine these models or
address them in completely different ways...

Orit.
 -----Original Message-----
From: 	Paul Kyzivat [mailto:[email-masked]] 
Sent:	Wednesday, June 19, 2002 2:18 PM
To:	Jonathan Rosenberg
Cc:	Orit Levin; 'Anders Kristensen'; Rohan Mahy; [email-masked]
Subject:	Re: [Sipping] Thoughts on the conf-info package

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

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

---

From: Orit Levin <[email-masked]>
Date: Sat, 22 Jun 2002 08:04:39 -0400

I completely agree that "mixing" issues and conferencing issues are separate
things. For example, you may have a SIP centralized Conference without
centralized "mixing" at all (i.e. Star Signaling with mesh Media.)
Additionally, I think that UA's "conferencing mixing capabilities" and a
specific conference "mixing characteristics" are different things. First may
be resolved by OPTIONS, the second by a media part of the Conferencing
Package or (preferably) by a separate package (to keep the separation
clear).
Keeping the separation in mind, I suggest that we define a solution to the
SIP conferencing requirements (without the mixing aspect) first.
I have two open issues with the proposed approach:
1.	Following the same path as above, UA's support for Conferencing
(i.e. Conferencing Package) is different from a SIP dialog being a part of a
specific Conference. The first one can be naturally signaled within the
Allowed-Events header. The second one requires a "Conference Identifier" and
must "belong" to a dialog. Does the Allow-Events header allow for such token
definitions?
2.	According to the "Conferencing Models" draft, the Conference
existence is signaled by a Conference "Service URI" within a Request URI (in
the Dial-in case) and within a "from" (in the Dial-out case).
* First, "by definition", this approach requires a "Conferencing Service" be
defined and identified. That is different from the spirit of the latest
proposal.
* Secondly, the resulted SIP dialogs in the add-hoc scenario and in the
dial-in/dial-out scenarios would look completely different.

-----Original Message-----
From:	Paul Kyzivat [mailto:[email-masked]] 
Sent:	Wednesday, June 19, 2002 2:18 PM
To:	Jonathan Rosenberg
Cc:	Orit Levin; 'Anders Kristensen'; Rohan Mahy; [email-masked]
Subject:	Re: [Sipping] Thoughts on the conf-info package

Jonathan,

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 25 Jun 2002 12:08:31 +0300

Jonathan
Thanks for the clarification. As for mixing. It is true that the mixer can
mix without telling who is mixed in this case it is an internal mixer
information. But if you want to let the users know who they see or hear or
to let them control the mix then they need the participants information
Roni Even 

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, June 24, 2002 11:41 PM
> To: Even, Roni
> Even, Roni wrote:
> > 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 you mean "conference or a user". Both are resources 
> identified 
> by the URI.
> 
> 
> > 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. 
> 
> Yes.
> 
> 
> > 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.
> 
> 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.
> 
> 
> --

---

From: Orit Levin <[email-masked]>
Date: Fri, 28 Jun 2002 11:44:13 -0400

OL: My comments are below.

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.

OL: Agreed.

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.

OL: Agreed with a note that the end-system doesn't have to become "a mixer"
for media in all cases. More precisely, it becomes the center of the star
SIP conference by maintaining correlation among SIP dialogs belonging to
this conference internally. It also manipulates the SDP of these dialogs in
order to construct the media graph of the conference.
If I understand correctly, if an UA is going to host a conference from the
beginning, it signals it by including the conference URI in the Contact
header of the first Invite towards each one of the participants.
Here I have a basic SIP question (sorry about that): How does the invited UA
know that he should specifically subscribe to a "Conferencing Package"
rather the any other potentially supported package? I would think that we
need to standardize the "service URI" FORMAT in order to distinguish among
different services with different packages.

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.

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

OL: We (i.e. the requirements draft) articulated the same requirement
slightly different:
" It MUST be possible to join a conference by a Conference ID"
This is exactly what we are trying to achieve. The UA doesn't need to "know"
that it is a conference. The human user would know it.
" It MUST be possible to join a conference or a session by any of the dialog
IDs, belonging to that conference or session"
If we agree on this requirement, this is exactly what the Join header would
be needed for. We need to check whether simple 3PCC scenarios (based on a
preliminary Join semantics) would tolerate the Contact being suddenly
changed to a Conference ID... But it definitely works for me.

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

OL: Sure. I would restrict this requirement to a conference host (center)
itself only. It relates to my next note about the "wildcard" (see below).

* 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

OL: Definitely with the exception of the "wildcard" scenario. It seems
inconsistent to me.
Let's say, a conference host has a number of conferences and/or sessions
going on. A UA would like to join a specific conference by knowing one of
its dialogs. If he knows the dialog ID, he is joining this conference.
Otherwise  (i.e. if he doesn't know the dialog ID), he "commands" the host
to merge all its conferences and calls together ??? It seems to me as a much
higher level primitive.

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

OL: Yes, they will.

BR,
Orit.

-Jonathan R.