Subject: [Sipping] comments on cc-framework

From: "Sanjoy Sen"<[email-masked]>
Date: Wed, 15 May 2002 13:07:59 -0500

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

[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: Rohan Mahy <[email-masked]>
Date: Wed, 15 May 2002 13:55:05 -0700 (PDT)

Sanjoy,

thanks for your comments.  a few response inline...

> a bit more generic. [\ss]

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

> must be globally routable. [\ss]

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.

> 2) The participant "type" may be another attribute - e.g., Conference

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.

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

> are Notified. A Conference "state" parameter - locked/unlocked - may be

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.

> publish Conference related information at some place, such as, # of reserved

agreed.  frequently this information can be provided indirectly (by URI)

> the status of the WG though).  [\ss]

ok

> perhaps WSDL and the client can use indirection to access the service

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

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

thanks,
-rohan

> More on the rest (Section 5 and beyond) later.

_______________________________________________
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