Subject: [Sipping] Comments on johnston-sipping-cc-conferencing-00.txt (the second duck in the line ;-)

From: "Arjun Roychowdhury" <[email-masked]>
Date: Thu, 31 Oct 2002 14:39:28 -0500

Hi,
My initial comments on this draft:

* Section 4.1 & 4.2: May be useful to use the same terminology across both 
of the new drafts. That would make 4.1 as 'basic participant'
and 4.2 a 'complex participant'

* Section 4.2 & 4.3: Ah, it seems your draft has further broken up the 
complex participant into one that can or cannot also be a focus.
And  one of the major differentitations between Type 2 & 3 seems types 3 
MAY need to support 3 URIs. Seems valid to me.
Any chance this further subclassification can be fed to Jonathan's draft 
for uniformity ?

*  Section 4.2: you say 
"From a SIP requirements perspective, a Type II UA would support REFER 
   [11], SIP Events [12], the conferencing package [13], and the 
conventions of conferencing call control defined in this document"

Do you mean it MUST support all of above or   a combination of one or more 
of the above ?

Section 5.2:  line 369 onwards, you clarify why an OPTIONS response would 
not respond with a list of active conferences.
However, the reason you sight for it seems to be that because there is no 
way to diff. a conference-uri . Well, if you anyway
plan to add isFocus, can you not add isConference ;-) ? 
I agree that it may generally not be a good idea to list all conferences 
in OPTIONS but the reason sighted in the explanation
does not seem to valid.

* Line 381, OPEN ISSUE: Should an OPTIONS request sent to a conference URI 
not 
      return the focus URI? Or the general URI? 

My take: Leave this as an implementation choice. Some implementations may 
NOT want to return the general-URI 
since it does not want to be addressed by that UA for any other 
functionality it may support besides conferencing.
Conversely, a feature server may want to return a 'general-URI' to the 
user telling him, 'hey you are using me as 
a conference server, but here is my general-uri - send me an OPTIONS there 
and Ill tell you what else I can do for you.
And while you are at it, make sure you have your credit card ready with 
you ' ;-)

* Various call flows: The call flows involing Alice and Carol seem to 
depict that assuming Alice is a complex participant,
she will get notified on Carol's presence only if Carol subscribes to the 
conference-server. Does that mean that if Carol
is a basic participant who does not SUB , Alice will not see her ? [  I 
guess not since your description states the Focus
should notify other users but the call flows seem to show them as only if 
this user does a SUB ]

(I see merits on both side: If Carol enters the conference and requires 
anonymity, she would probably do that in the events 
package sent after INVITE. In that case, the NOTIFY to Alice should not 
tell her its Carol. However, if Carol never
sent a SUB after joining the conference, it may well be a basic UA and 
thefore, Alice should be told a new user has entered.
So how will this work ? Does Carol's privacy requirements need to be 
negotiated before she joins the conference ? )

Edit Nits:
* line 174, sec 3.1: s/unware/unaware/
* "bookmark not defined" in various places ;-)

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066
_______________________________________________
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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 31 Oct 2002 16:29:47 -0600

Hi Arjun,

Thanks very much for your comments.  See my comments below.

Just one comment about how we hope this document will fit in with the other 
documents.  We see it being similar to cc-transfer and other call control 
usage SIPPING documents that are well-defined, relatively self-contained 
documents for implementors to use to make services using a specific 
approach (in this case, how to make a tightly coupled SIP conference work).

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

>and 4.2 a 'complex participant'

Yes - cc-conferencing terminology is aligned with the conferencing 
requirements draft -01 (from July) and -02 (to come out next week) but not 
with the framework.  The design team will  work this out.

>Any chance this further subclassification can be fed to Jonathan's draft

Yes.

>Do you mean it MUST support all of above or   a combination of one or more

There is no current requirement do distinguish between a Type I 
(conferencing unaware) UA and a Type II (conference member capable) UA.  A 
non-normative difference is that a Type II would recognize the "isFocus" 
parameter and likely support many of the call control flows shown in the 
document.

>in OPTIONS but the reason sighted in the explanation

Perhaps - isConference is an interesting idea.  The process of defining 
caller prefs extensions for conferencing has barely begun, so we shall see 
what the requirements dictate.

>And while you are at it, make sure you have your credit card ready with

Right - if we leave it open we at least need to discuss what will happen as 
a result. This entire OPTIONS usage needs more thought, especially how it 
will interact with Type I (conferencing unaware) UAs.

>should notify other users but the call flows seem to show them as only if

There is no dependency on Carol's sending a SUBSCRIBE and Alice receiving a 
NOTIFY. It is just hard to show asynchronous events in a linear callflow :-)

>negotiated before she joins the conference ? )

The design team is beginning to discuss exactly this issue. It is likely 
that Carol will indicate in a header or parameter in her INVITE that she 
wishes to be added anonymously and the focus will either accept (and honor) 
or reject her request.

>* "bookmark not defined" in various places ;-)

Yes, I'm becoming a fan of writing I-Ds using xml ;-)