Re: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt
aroychow@hss.hns.com Sat, 22 February 2003 15:39 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12242 for <sipping-archive@odin.ietf.org>; Sat, 22 Feb 2003 10:39:27 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1MFl2222785 for sipping-archive@odin.ietf.org; Sat, 22 Feb 2003 10:47:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MFl2p22782 for <sipping-web-archive@optimus.ietf.org>; Sat, 22 Feb 2003 10:47:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12235 for <sipping-web-archive@ietf.org>; Sat, 22 Feb 2003 10:38:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MFjrp22708; Sat, 22 Feb 2003 10:45:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1MFgPp22602 for <sipping@optimus.ietf.org>; Sat, 22 Feb 2003 10:42:25 -0500
Received: from gateway.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12128; Sat, 22 Feb 2003 10:34:17 -0500 (EST)
From: aroychow@hss.hns.com
Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h1MFc5J3022949; Sat, 22 Feb 2003 10:38:05 -0500 (EST)
Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1MFc0D22180; Sat, 22 Feb 2003 10:38:00 -0500 (EST)
To: shaj@cisco.com
Cc: sipping@ietf.org, sipping-admin@ietf.org
Subject: Re: [Sipping] Comments on draft-rosenberg-sipping-conferencing-framework-01.txt
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
Message-ID: <OF4AF97A8A.5CEA3D53-ON85256CD5.005355DD@LocalDomain>
Date: Sat, 22 Feb 2003 10:37:44 -0500
X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 02/22/2003 10:36:02 AM, Serialize complete at 02/22/2003 10:36:02 AM
Content-Type: multipart/alternative; boundary="=_alternative 0055D6DB85256CD5_="
X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h1MFc0D22180
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
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 0066{@vtext.com} "Shiva" <shaj@cisco.com> Sent by: sipping-admin@ietf.org 02/22/2003 01:57 AM Please respond to shaj To: <sipping@ietf.org> 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 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
- [Sipping] Comments on draft-rosenberg-sipping-con… Shiva
- Re: [Sipping] Comments on draft-rosenberg-sipping… aroychow
- Re: [Sipping] Comments on draft-rosenberg-sipping… Zon-Yin Shae
- Re: [Sipping] Comments on draft-rosenberg-sipping… Jonathan Rosenberg