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

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

Rohan Mahy wrote:

>>Of course, the conference URI must be registered, but I think this is
>> a
>>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:A@1.2.3.4
> 
> reINVITE B
> Contact: A;conf=1@1.2.3.4

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.


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

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.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP