Subject: Re: [Sipping] Initial comments on conferencing-framework-00.txt { resend }

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Dec 2002 23:16:24 -0500

Arjun,

Thanks for your comments. Responses inline.

Arjun Roychowdhury wrote:

> * Line 189: Definition of focus, you say:
> " The   focus is responsible for insuring, in some way, that each 
> participant receives the media that make up the conference"
> 
> Do we need to write the above  ? The fact that it maintains signalling 
> relationship seems to make the following statement
> implicitly assumed.

We definitely need to say it. There was debate amongst the design team 
as to whether this was even true, so clearly its not obvious...

> 
> 
> * line 362 (section 3): In the terminology section, you outline as 'Basic 
> conference' as one that has only a focus. Here you say
> that in a basic conference, the focus actually has an access to a 
> conferencing policy and a media policy, but are administratively
> provision. 
> 
> Herein lies my doubt: Any conference (including a basic one) will have, as 
> 
> you mention, some sort of access to a
> 'policy'. Therefore, can we define a 'basic conference' concretely , since 
> 
> how it interacts with the conference policy server
> and media policy server are impl. dependant. I noticed that you have 
> defined a 'Conference Policy Control Protocol' and
> a 'Media service Control protocol'. Do you plan to defines these protocols 
> 
>  and classify a basic conference as ones who
> do not implement these speficic protocols ? I guess not since later you 
> say these interfaces are not subject to standardization.
> My take is that even a 'basic conference' has to have some kind of policy 
> interaction - which makes it a complex conference.

The current plan in the design team is to drop "basic conference" as a 
term, since it adds little value. What is more important is the notion 
of a basic participant, now renamed to "conference unaware participant" 
which is much more intuitive than either "basic participant" or "type I 
participant".

> 
> 
> 
> * line 1373 (sec 7.1): OPEN ISSUE: Do we need to specify standards for 
> this? [naming of conferencing servers]
>         Personally, I dont think its necessary. Unlike, say,a  default 
> proxy/registrar for which we provide SRV location
>         , a conferencing server is an application which is not critical to 
> 
> routing or bootup of an end device.

In fact, the idea of "instant conferences" are really a type of 
application, and so we decided outside the scope of the framework.

> 
> 
> * Section 7.2: The case where a new participant is added as a result of an 
> 
> INVITE originating from the focus. 
> 
> Im confused by this section. The draft describes a scenario as such:
> User Jack (who is already in the conference) wants to invite friend Jill 
> into the conference. Therefore, Jack uses the
> 'control policy control protocol' to ask the Focus to invite Jill. 
> However, Jill has the liberty of rejecting this invitation
> by the focus if certain conditions of his are not met. 
> 
> Till now, things make sense to me. But then, line  1469 states:
> 
> "To accomplish    this, the conference policy control protocol is used to 
> establish
>    these policies *prior* to the *generation* or acceptance of an 
> invitation    to the conference."
> 
> How is this possible ? Jill does not know of the conference or that fact 
> that Jack wanted her in it. The first
> 'intimation' of the fact that Jill is being invited, therefore, would be 
> the INVITE message being sent to her.

Well, all of this is an open issue more or less. THe example about 
manipulating conference policy before joining was for the explicit case 
where the participant-to-be knew the conference URI ahead of time (from 
a web page, for example).

> 
> Therefore, it seems most likely to me that these negotiations will happen 
> after the generation but possibly
> prior to the acceptance of the INVITE. The bad part I see in this is that 
> what I am assuming is that the INVITE
> transaction will be on hold till the policy negotiation is done. But the 
> alternate of the user manipulating policies
> before he gets into a conference does not seem logical to me.

If the conference URI is known ahead of time, it does make sense to 
manipulate the policies first. Whether that is the right approach is a 
good question.

> 
> Also, a long pending question. In this mode, what if when Jack says, ' 
> Please invite Jill' to the focus
> and the focus itself has a pre-condition that says ' Well, ok, I will 
> invite Jill only if she can authenticate with me first'.
> In this case, since Focus sends the INVITE, how does it ensure Jill 
> authenticates herself ? Is this again going
> to be a 'conference policy protocol' that is not (neccesarily) SIP ?

Standard SIP authentication mechanisms. However, authentication of 
called parties is much less of an issue. So long as you have the right 
URI for the user, and the system is authenticating registrations, an 
INVITE for a user should route to that user unless a proxy or the DNS 
have been compromised, or certain active mitm attacks are launched. All 
are pretty unlikely. Thats why people consider reverse email a 
reasonable form of authentication...

> 
> 
> 7.5 : Creating Sidebars
> At first read, to me, a 'conference within a conference' seems much 
> cleaner than media policy. The same 
> conference class could create another instance to create this new 
> 'sidebar' conference. 
> But since there it is still unclear to the team on which approach to take, 
> 
> obviously, Im oversimplifying the conference-
> within-conference issue. Could you share your thoughts on possible issues 
> with this approach ?

I personally favor conference in-a-conference as well. The primary issue 
is that it makes it impossible for conferencing-unaware participants to 
be involved in the sidebar. If the sidebar were done with media 
policies, a conference-unaware participant could be involved.

> 
> 
> Edit nits:
> 
> line 192 (pg 4) : s/insuring/ensuring/

ok

> line 305: s/an singleton/a singleton/

We removed singeton as a definition in -01 so its a non-issue.

> line 652 (Sec 5.1) s/insures/ensures/

ok

> line 144 (sec 1) s/referrrer/referrer/

fixed

> line 331 (page 6) s/dicsussion/discussion/

fixed

> line 1458 (sec 7.3) s/particicular/particular/

thanks

> line 1588 (sec 8) s/the the/the/

done

Thanks for your comments,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP