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

From: Orit Levin <[email-masked]>
Date: Fri, 28 Jun 2002 12:29:57 -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.

_______________________________________________
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