Subject: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt

From: "Shiva" <[email-masked]>
Date: Sat, 22 Feb 2003 12:27:46 +0530

Hello,
 
Overall the draft looks good.  Here are some of my comments on this
draft
 
The idea of having a unique URI for each conference is a good one.
However a more scalable approach would be to have a master Focus or a
group of them that register with a standard URI. This way users use a
standard URI with a Conference ID as the payload in the Invite message.
This is directed to the master Focus that does the following
* Retrieve the Conference ID
* Check if a Focus corresponding to the conference exists
* If the Conference specific Focus  does not exist create a new Focus
with a unique URI derived from the Conference ID
* Forward the call using the standard Refer mechanism to the new Focus
with the Unique URI.
 
The advantage of doing this is that I could have multiple Conference
servers that are running that are registered their master focus. 
 
We can implement Load Balancing across Conference servers without the UA
realizing it as it is not connecting to a specific Focus on a specific
server. A second advantage is that if in the course of a meeting if the
focus were to go down or the server went down the participants can
attempt to rejoin the call. In such a case the Master Focus would see
that the Conference specific focus is down and recreate it allowing
users to quickly rejoin the conference.
 
Of course one needs to work out the details of the communication and
keepalive between the Master Focus and the Conference focus it creates.
 
The other advantage is if there are global Conference policies these can
be applied at the master and the Individual Conference focus needs to
worry about the specifics of the conference it is dealing with.
 
The other comment was in the area of the Conference policy control
protocol. Is this something like the SDP which is carried as a payload
in SIP or does it have specifics of it's own. Currently most of the
operations that are part of the CPCP are also possible through SIP based
mechanisms. Is there a need to define two parallel mechanisms within the
same framework. 

Instead of dealing with Conference aware UA's and Conference Unaware
UA's we could assume all participants in the Conference to be Conference
Aware. The Conference Unaware participants are routed through a Gateway
(e.g. an IVR ) that provides a primitive interface to the conference
unaware participants and a Conference aware interface to the Conference
itself.  This would keep the model simpler and it can allow Conference
aware UAs a way to control the conference.
 
Regards
Shiva
Cisco Systems

---

From: [email-masked]
Date: Sat, 22 Feb 2003 10:37:44 -0500

Inline prefixed by <ARC>

The idea of having a unique URI for each conference is a good one. However 
a more scalable approach would be to have a master Focus or a group of 
them that register with a standard URI. This way users use a standard URI 
with a Conference ID as the payload in the Invite message.  This is 
directed to the master Focus that does the following
* Retrieve the Conference ID
* Check if a Focus corresponding to the conference exists
* If the Conference specific Focus  does not exist create a new Focus with a unique URI derived from the Conference ID
* Forward the call using the standard Refer mechanism to the new Focus 
with the Unique URI.
 
<ARC>
 You may also want to read 
http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sipping-cc-conferencing-01.txt.
Its provides the definition of a conference Factory URI, which could be 
used to create new conferences and their Focii.
Note that when you send an INVITE to a factory URI, that entity returns 
the actual Conference-URI in the Contact header.
Also, you may be using a central 'conference enabling application' that 
asks you lots of questions before allowing you to create/join  a new
conference. See an example of that in 4.3 of alan/orit's draft.
Note however , that when you want to use a "standard wellknown URI" that 
has not been published to you by the conference server,
you are assuming that there is some agreement for that domain on 
conference naming policies.
I am not sure I like your idea of a payload contaning conf-id (what use is 
that ?)
Also, note that for scalability (if thats your primary concern), this 
mechanism allows a way for you to start with a 'guessed URI' and from
then on communicate directly with you assigned focus without routing 
everthing to what you call your 'master focus'. 
</ARC>

Instead of dealing with Conference aware UA's and Conference Unaware UA's 
we could assume all participants in the Conference to be Conference Aware. 
The Conference Unaware participants are routed through a Gateway (e.g. an 
IVR ) that provides a primitive interface to the conference unaware 
participants and a Conference aware interface to the Conference itself. 
This would keep the model simpler and it can allow Conference aware UAs a 
way to control the conference.

<ARC>
 It is extremely important to acknowledge conference-unaware endpoints. 
You cannot assume an IVR or any other application in all 
conference scenarios who 'aware' on behalf of an unaware UA. Again, 
reading both Jonathan and Alan/Orit's draft in conjunction may motivate
you more on the requirement of conference unaware UAs. Remeber also , that 
most of the EPs deployed in SIP have zilch idea of what isFocus is
as well as will not be aware of protocols to moderate a conference for a 
while.
</ARC>

The other comment was in the area of the Conference policy control 
protocol. Is this something like the SDP which is carried as a payload in 
SIP or does it have specifics of it's own. Currently most of the 
operations that are part of the CPCP are also possible through SIP based 
mechanisms. Is there a need to define two parallel mechanisms within the 
same framework. 

<ARC>
I think what has been identifed here is a need for a conference policy 
control protocol. It is not ascertained yet which protocol will deliver 
these
requirements. Thats as far as I know. The existing SDP specs do not meet 
all control requirements that come to my mind. 

Alan - would you mind reposting that link of conferencing work in progress 
 ? I thought I noticed some drafts attempting to address this in more 
detail

Now a question again for the authors of 
draft-johnston-sipping-cc-conferencing-01.txt:

* section 4.5 callflow - you show alice sending an invite to a 
conf-factory URI but the ladder diagram shows it being received by a 
'Focus'.
The definition of a focus 

3.1 Focus UA

   A focus, as defined in the framework, hosts a SIP conference and
   maintains a SIP signaling relationship with each participant in the
   conference. A focus contains a conference-aware user agent that
   supports the conferencing call control conventions as defined in this
   document.

Since a 'Focus' hosts 'a specific' conference, I find it a little 
disconcerting
that the call flows show messages with a factory-URI reaching a focus. I 
thought
it may be clearer, if we limit a 'focus' to be the target of a specific 
URI meant
for a specific conference. If a person sends an INVITE to a factory-URI or
a 'conf-app-URI' < like an IVR etc which then contacts a Factory after 
auth etc>
it should not be received by a Focus, should it ?

</ARC>

regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860  (M): 240 997 [email-masked]}

"Shiva" <[email-masked]>
Sent by: [email-masked]
02/22/2003 01:57 AM
Please respond to shaj

        To:     <[email-masked]>
        cc: 
        Subject:        [Sipping] Comments on 
draft-rosenberg-sipping-conferencing-framework-01.txt

Hello,
 
Overall the draft looks good.  Here are some of my comments on this draft

We can implement Load Balancing across Conference servers without the UA 
realizing it as it is not connecting to a specific Focus on a specific 
server. A second advantage is that if in the course of a meeting if the 
focus were to go down or the server went down the participants can attempt 
to rejoin the call. In such a case the Master Focus would see that the 
Conference specific focus is down and recreate it allowing users to 
quickly rejoin the conference.

 
The other comment was in the area of the Conference policy control 
protocol. Is this something like the SDP which is carried as a payload in 
SIP or does it have specifics of it's own. Currently most of the 
operations that are part of the CPCP are also possible through SIP based 
mechanisms. Is there a need to define two parallel mechanisms within the 
same framework. 

Instead of dealing with Conference aware UA's and Conference Unaware UA's 
we could assume all participants in the Conference to be Conference Aware. 
The Conference Unaware participants are routed through a Gateway (e.g. an 
IVR ) that provides a primitive interface to the conference unaware 
participants and a Conference aware interface to the Conference itself. 
This would keep the model simpler and it can allow Conference aware UAs a 
way to control the conference.
 
Regards
Shiva
Cisco Systems

---

From: Zon-Yin Shae <[email-masked]>
Date: Fri, 28 Feb 2003 09:15:32 -0500

Overall the draft looks good.  I wish this conference frame work can be
extended to cover the following enterprise/service conferencing scenario:

When an application need a conference service, it only creates a conference
ID (and its associated policy).  By the time the application does not know
(does not want to or can not specify) which conference service ( Focus) to
use.   Moreover,  it is desired for the performance and scalability that a
set of Focuses should work collaboratively to perform the distributed
conference service.  For example, 20 participants in a conference,   10 in
CA and 10 in NY,  it is better to have two Focuses (one in CA and one in
NY) to jointly perform the service.   Protocols among Focuses are required.

Also, most of VoIP phone does support ad-hoc conference capability and is
an useful media mixing resource.  It can be useful (for the resource usage
and scalability) that the Focus can delegate some of the media mixing
function to be performed in these phones of the conference participants.
Protocols among Focus and participants are required.

There are some components are required in the above scenario to achieve the
dynamic conference configuration.     .

1.  A conference is identified by a conference ID.  A conference might be
collaboratively serviced by more than one Focuses.  Since URI is used for
routing to only one UA, it would be more appropriate to carry the
conference ID (and its associated policy) in the payload with standard URI.

2. The default Focus for a UA can be pre-configured or discovered using
similar procedure of outbound proxy (or proxy server).

3. Protocols among Focuses (and conference policy server) are required.
The Subscribe and Notify SIP mechanism with extended SDP can be used among
Focuses to establish a collaboratively distributed service for a
conference.

4. Protocols between Focus (and conference policy server) and participants
are required.   In Figure 2, the conference policy control protocol is only
one way (from participant to conference policy server), it can be two way
protocol to make use of the mixing resources in the participants (e.g.,
VoIP phone).   One possibility is to extend REFER mechanism using
(extended) SDP for carrying conferencing policy.

Regards,

zon-yin shae
IBM Watson Research Center

[email-masked]@ietf.org on 02/22/2003 10:37:44 AM

To:    <[email-masked]>
cc:    [email-masked], [email-masked]
Subject:    Re: [Sipping] Comments on
       draft-rosenberg-sipping-conferencing-framework-01.txt

Inline prefixed by <ARC>

The idea of having a unique URI for each conference is a good one. However
a more scalable approach would be to have a master Focus or a group of them
that register with a standard URI. This way users use a standard URI with a
Conference ID as the payload in the Invite message.  This is directed to
the master Focus that does the following
* Retrieve the Conference ID
* Check if a Focus corresponding to the conference exists
* If the Conference specific Focus  does not exist create a new Focus with
a unique URI derived from the Conference ID
* Forward the call using the standard Refer mechanism to the new Focus with
the Unique URI.

<ARC>
 You may also want to read
http://www.iptel.org/info/players/ietf/conferencing/draft-johnston-sipping-cc-conferencing-01.txt
.
Its provides the definition of a conference Factory URI, which could be
used to create new conferences and their Focii.
Note that when you send an INVITE to a factory URI, that entity returns the
actual Conference-URI in the Contact header.
Also, you may be using a central 'conference enabling application'
that  asks you lots of questions before allowing you to create/join  a new
conference. See an example of that in 4.3 of alan/orit's draft.
Note however , that when you want to use a "standard wellknown URI" that
has not been published to you by the conference server,
you are assuming that there is some agreement for that domain on conference
naming policies.
I am not sure I like your idea of a payload contaning conf-id (what use is
that ?)
Also, note that for scalability (if thats your primary concern), this
mechanism allows a way for you to start with a 'guessed URI' and from
then on communicate directly with you assigned focus without routing
everthing to what you call your 'master focus'.
</ARC>

participants and a Conference aware interface to the Conference

<ARC>
 It is extremely important to acknowledge conference-unaware endpoints. You
cannot assume an IVR or any other application in all
conference scenarios who 'aware' on behalf of an unaware UA. Again, reading
both Jonathan and Alan/Orit's draft in conjunction may motivate
you more on the requirement of conference unaware UAs. Remeber also , that
most of the EPs deployed in SIP have zilch idea of what isFocus is
as well as will not be aware of protocols to moderate a conference for a
while.
</ARC>

The other comment was in the area of the Conference policy control
protocol. Is this something like the SDP which is carried as a payload in
SIP or does it have specifics of it's own. Currently most of the operations
that are part of the CPCP are also possible through SIP based mechanisms.
Is there a need to define two parallel mechanisms within the same
framework.

<ARC>

Alan - would you mind reposting that link of conferencing work in
progress  ? I thought I noticed some drafts attempting to address this in
more detail

Now a question again for the authors
of  draft-johnston-sipping-cc-conferencing-01.txt:

* section 4.5 callflow - you show alice sending an invite to a conf-factory
URI but the ladder diagram shows it being received by a 'Focus'.
The definition of a focus

3.1 Focus UA

Since a 'Focus' hosts 'a specific' conference, I find it a little
disconcerting
that the call flows show messages with a factory-URI reaching a focus. I
thought
it may be clearer, if we limit a 'focus' to be the target of a specific URI
meant
for a specific conference. If a person sends an INVITE to a factory-URI or
a 'conf-app-URI' < like an IVR etc which then contacts a Factory after auth
etc>
it should not be received by a Focus, should it ?

</ARC>

regds
Arjun

                                                                           
     "Shiva"                                                               
     <[email-masked]>                    To:        <[email-masked]>     
     Sent by:                            cc:                               
     [email-masked]                Subject:        [Sipping]         
     rg                          Comments on                               
                                 draft-rosenberg-sipping-conferencing-fram 
     02/22/2003 01:57 AM         ework-01.txt                              
     Please respond to                                                     
     shaj                                                                  

Hello,

Conference specific focus is down and recreate it allowing users to quickly
rejoin the conference.

The other advantage is if there are global Conference policies these can be
applied at the master and the Individual Conference focus needs to worry
about the specifics of the conference it is dealing with.

The other comment was in the area of the Conference policy control
protocol. Is this something like the SDP which is carried as a payload in
SIP or does it have specifics of it's own. Currently most of the operations
that are part of the CPCP are also possible through SIP based mechanisms.
Is there a need to define two parallel mechanisms within the same
framework.

participants and a Conference aware interface to the Conference

Regards
Shiva
Cisco Systems

_______________________________________________
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