RE: [Sipping] Comments on draft-rosenberg-sipping-conferencing-fr amework-01.txt

[Orit Levin <[e-mail]>]

I agree with most of Arjun's analysis. My comments are inline (OL:).
 
Orit.
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Saturday, February 22, 2003 10:38 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [Sipping] Comments on
draft-rosenberg-sipping-conferencing-framework-01.txt
 
---skip
 * 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-c
c-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. 
---skip
</ARC> 
OL: The cc-conferencing does take into consideration this scenario i.e.
Referring to a focus by a conference factory. The statement in 3.2 "the
Conference Factory URI and the newly created focus URI MAY resolve to
different physical devices" targets the exact case. We even had this
scenario included in one of the intermediate versions of the draft. We can
restore the example if the readers find it helpful. 
 
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.
 
 OL: I agree that this is one of the possible ways to implement Load
Balancing. The Factory-Focus "decomposition" allows for that without
requiring the factory to forward SIP messages during stable sessions. I am
much less sure about the second advantage - redundancy. It is still can be
implemented with additional interface between the factory and its focuses
(as Shiva points out) but I wouldn't impose standard SIP
procedures/conventions in order to implement it - there are so many
(proprietary and standard) ways to address redundancy that I wouldn't put it
as a requirement for SIP conferencing.
 
...skip
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. 
...skip
<ARC> 
 It is extremely important to acknowledge conference-unaware endpoints. 
...skip
</ARC> 
OL: One of the first requirements (in the conferencing-requirements draft)
is to be able to accommodate basic UAs in a SIP conference. That being said
based on the chosen approach (and the examined scenarios) on the SIP level
there is no need for differentiation between conference-aware and
conference-unaware participants neither for a conference factory nor for a
focus. 
...skip
<ARC> 
...skip
 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>
OL:  I agree with this comment - the picture on its own is "disconcerting".
In the shown scenario the factory and the focus are logical entities that
located in a single physical device (called "focus" in the picture). We will
either rearrange the drawing or add a text clarifying the case.
Thanks you, guys, for all your comments,
Orit.