Subject: RE: [Sipping] comments on cc-framework

From: Orit Levin <[email-masked]>
Date: Wed, 15 May 2002 17:00:01 -0400

Hi Sanjoy!
 
One of the outcomes of the interim meeting was the decision to move the
conferencing detailed discussion from the "cc-framework" to the
"conferencing requirements". We will drop the meta-model and the detailed
media requirements from the "conferencing requirements" and align the
terminology with the "cc-framework" and other SIP drafts. We will leave the
SIP Star model and group the conferencing requirements according to their
topics (areas). For each requirement we will suggest SHALL/SHOULD/etc. for
further discussion.
 
As a part of this job, a number of your concerns will be automatically
addressed (such as conferencing global identification vs. description,
generalizing "mixing concept" and detaching it from the RTP, etc.) 
 
I look forward getting more remarks and conferencing requirements so that we
would be able to address them in the "conferencing-requirements" draft.
 
Orit .
 
-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 2:08 PM
To: [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'
Cc: [email-masked]; Sanjoy Sen
Subject: [Sipping] comments on cc-framework
 
Hi, 
Some comments on the draft-ietf-sipping-cc-framework-00.txt. Some of these
may already have been discussed - sorry for any duplication!
------- 
   4.3.1  (Single) End System Mixing 
   ... 
   From an RTP perspective, A is 
   a mixer, and so the RTCP reports from A will contain SDES 
   information that indicates the existence of an additional party in 
   the media stream. 
[ss] What about media sessions not using RTP such as white-boarding 
or a future collaboration application or multiplayer gaming. This section
(4.3) 
on media mixing models are RTP-centric. I think there's a need to make it 
a bit more generic. [\ss] 
   4.3.2.2 Ad-hoc Centralized Conferences 
   . . . 
   The conference ID is then prepended 
   to the server, and a SIP URL for the ad-hoc conference is formed. 
   For example, if the server "a.servers.com" is used, and the unique 
   ID is "a7hytaskp09878a", the SIP URL for this conference is 
   sip:[email-masked]. 
[ss] There is an additonal requirement here that the URI as formed above 
must be globally routable. [\ss] 
   4.4 Conveying Information and Events 
   ... 
[ss] These are some requirements for Call/Conference-Info packages (perhaps
I 
should post them separately): 
1) An user may want to join the conference as an anonymous user, in which
case 
his/her presence won;t be announced. 
2) The participant "type" may be another attribute - e.g., Conference
coordinator 
vs ordinary participants 
3) A Conference "site" parameter may be required to abstractly represent 
a list of participants (this came out of discussions at Interim) - e.g.,
Europe, 
North American site etc. A conference site may consist of multiple mixing
elements. 
4) A conference may be locked in the absence of a Chair and when the Chair 
joins the conference, the conference is unlocked and all the intended
participants 
are Notified. A Conference "state" parameter - locked/unlocked - may be
needed for this. 
5) Also, important for a meet-me conferences, there's the need to 
publish Conference related information at some place, such as, # of reserved

ports, password-protected or not. This can be published using non-sip URI's.

[\ss] 
  
   4.5.1.1 Mixer 
   ..... 
[ss] The definition of a mixer is again very RTP centric. The concept of a
mixer (sending 
an user the combined media from all other participants) can be generalized
for 
any non-RTP applications such as whiteboarding, multiplayer gaming etc.
[\ss] 
   4.5 Componentization and Decomposition 
   ... 
   For many of these components it is also desirable to discover their 
   capabilities, for example querying the ability of a mixer to host a 
   10 dialog conference, or to reserve resources for a specific time. 
   These actions could be provided in the form of URLs, provided there 
   is an a priori means of understanding their semantics. 
[ss] The work of the RESCAP working group may be worth looking into (not
sure about 
the status of the WG though).  [\ss] 
   4.6 Use of URI's 
   .... 
   In our example, the user portion of the address, 
   "annc",  specifies the announcement service on the media server. 
   The two URI parameters "play=" and "early=" specify the audio 
   resource to play and whether early media is desired. 
       sip:[email-masked]; 
       play= http://audio.carrier.net/allcircuitsbusy.au;early=yes
<http://audio.carrier.net/allcircuitsbusy.au;early=yes>  
 
[ss] URI's are meant to be resource locators and not as resource 
descriptors, e.g., tagging a conference URL with all the features of a
service 
and make it a mile long URI doesn't sound very efficient. Use of Service
Indirection 
may be more appropriate - e.g., the publication of a service feature
description using 
perhaps WSDL and the client can use indirection to access the service
feature 
document. [\ss] 
   4.8 Billing issues 
   ... 
[ss] It may be appropriate to mention here that doing 3pcc using a B2BUA can
facilitate 
billing through dialog correlation. [\ss] 
More on the rest (Section 5 and beyond) later. 
Thanks, 
Sanjoy

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 16 May 2002 10:01:57 -0500

Some more comments inline. Thanks.

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, May 15, 2002 3:55 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]
> Subject: Re: comments on cc-framework
> 
> 
> Sanjoy,
> 
> thanks for your comments.  a few response inline...
> 
> On Wed, 15 May 2002, Sanjoy Sen wrote:
> 
> > Hi,
> > Some comments on the 
> draft-ietf-sipping-cc-framework-00.txt. Some of these
> the intent wasn't to be RTP specific, but to give some concrete
> relationship between a SIP mixer and an RTP mixer (since the later is
> already defined).
> 
   I would suggest adding something like this towards the end of section 4.3
Mixing Models :
"Although RTP/RTCP is used here as an example media transport, the following
models do not preclude 
conference sessions with non-RTP media such as whiteboarding, chat or
multiplayer gaming."

> ok, I was assuming that, but I can spell that out.
> 
> > I  should post them separately):
> there are two different things here:
> announcing a user who happens to be anonymous
> advertising a roster which excludes "hidden" participants 
> (any of whom may
> or may not be anonymous.  we should allow for both.
> 

agree. Perhaps some text is needed for this?

> i'll push back here.  i don't think you are a conference 
> participant OR a
> moderator OR a coordinator.  You are either a participant or 
> not.  As a
> completely orthogonal attribute, you may have chair permissions for a
> conference.  I think it is completely reasonable to have chair
> permissions for a conference that you do not participate in.
> 
Yes, I was intending to move towards that direction:-) The difference will
be
from the pov of permissions/rights. I'm not sure whether we need to spell
participant attributes such as these in the Conference-info package or
is there a need for a separate Conference-actors-info package? For example,
the 
Conference Coordinator role may change from one person to another during the
conference 
& this may need to be notified to the participants.

> > Europe, North American site etc. A conference site may consist of
> > multiple mixing elements.
> 
> I think this is a policy decision on the part of each mixer, how they
> represent themselves to other mixers.  You might provide 
> complete roster
> transparency by recursing.
> 
ok.

> again, I think this is an implementation detail.  what does 
> it mean when
> the conference is locked?  can I join?  can I leave?  can I 
> communicate
> with other participants?  I don't think there is anythign 
> fundamental or
> atomic about locking a whole conference.
> 
Well, I was thinking more of the situation where the participants are not
allowed to participate in a conference until the Chairperson joins. I may
just want 
to be notified when the Chairperson joins, instead of dialing into
the conference server and waiting.

> agreed.  frequently this information can be provided 
> indirectly (by URI)
> 
> ok
> >        play=http://audio.carrier.net/allcircuitsbusy.au;early=yes
> >
> >
> i think there is a lot of value in these conventions when the 
> function is
> simple (for example, play) and common.  I agree that we don't want to
> encode every feature in a mile-long URI
> 
> >    4.8 Billing issues
> >    ...
> >
> > facilitate billing through dialog correlation. [\ss]
> 
> I don't think that helps the correlation problem.  It seems 
> like you are
> just moving the problem around.  Can you explain why you 
> think this helps?
> 
Since the controller is establishing all the dialogs, it always knows who
established the call & can atleast do a PSTN style billing. Also, a side
question-
what is SIP-style billing?

Thanks,
Sanjoy

> thanks,
> -rohan

---

From: "Sanjoy Sen"<[email-masked]>
Date: Tue, 21 May 2002 10:05:31 -0500

Hi Orit et. al.,
 
Here's some centralized conferencing requirements as input to the
"conferencing requirements" draft mentioned in your email below. The list
being too long to publish as a plain email, I've assembled them in a small
draft and attached it to this email. I suggest that we discuss this  (and
others as well) in the list and include them in the draft worked by the
design team. As usual, comments/flames are most welcome! 
 
Note that, a few of these requirements may be out of scope with SIP but I
wanted to create the laundry list first before we went about determining
what is in scope and what is not.
 
Cheers,
Sanjoy
============================= 
Succession VoIP Group 
Nortel Networks
Phone: (972) 685-8274 
Fax: (972) 684-3986 
E-mail: [email-masked] <  <mailto:[email-masked]>
mailto:[email-masked]> 

-----Original Message-----
From: Orit Levin [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 4:00 PM
To: Sen, Sanjoy [NGC:B692:EXCH]; [email-masked]';
[email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]
Subject: RE: [Sipping] comments on cc-framework

Hi Sanjoy!

 
 
Orit .
 
-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 2:08 PM
To: [email-masked]'; [email-masked]';
 
Hi, 

[\ss] 
  
   4.5.1.1 Mixer 
   .....