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

[Paul Kyzivat <pkyzivat@cisco.com>]

This is sounding good! Another comment below.

	Paul

Jonathan Rosenberg wrote:
> 
> 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.
... 
> 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

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.

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

_______________________________________________
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