From wwwrun@rfc-editor.org Thu Apr 11 14:44:50 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D71721F8712; Thu, 11 Apr 2013 14:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzCcMngln1pg; Thu, 11 Apr 2013 14:44:49 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DD91C21F86C3; Thu, 11 Apr 2013 14:44:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 51DDEB1E003; Thu, 11 Apr 2013 14:44:09 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130411214409.51DDEB1E003@rfc-editor.org> Date: Thu, 11 Apr 2013 14:44:09 -0700 (PDT) Cc: mediactrl@ietf.org, rfc-editor@rfc-editor.org Subject: [MEDIACTRL] RFC 6917 on Media Resource Brokering X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:44:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6917 Title: Media Resource Brokering Author: C. Boulton, L. Miniero, G. Munson Status: Standards Track Stream: IETF Date: April 2013 Mailbox: chris@ns-technologies.com, lorenzo@meetecho.com, gamunson@gmail.com Pages: 136 Characters: 280399 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mediactrl-mrb-19.txt URL: http://www.rfc-editor.org/rfc/rfc6917.txt The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. This document is a product of the Media Server Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From eburger@standardstrack.com Fri Apr 12 16:20:43 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F75A21F8EA5 for ; Fri, 12 Apr 2013 16:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82Hn8sTz6e8Y for ; Fri, 12 Apr 2013 16:20:42 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.237]) by ietfa.amsl.com (Postfix) with ESMTP id A601321F8EAF for ; Fri, 12 Apr 2013 16:20:42 -0700 (PDT) Received: from 1-193.icannmeeting.org ([199.91.193.1]:1083 helo=[10.196.202.183]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UQnGd-0001qf-3f for mediactrl@ietf.org; Fri, 12 Apr 2013 16:20:33 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_407DE4F0-7414-4498-BFE5-F8BEDA595D38"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <0A241228-2798-42D3-B03C-BF896BBC267F@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Fri, 12 Apr 2013 16:07:14 -0400 References: <20130411214409.51DDEB1E003@rfc-editor.org> To: mediactrl@ietf.org In-Reply-To: <20130411214409.51DDEB1E003@rfc-editor.org> X-Mailer: Apple Mail (2.1503) X-OutGoing-Spam-Status: No, score=-1.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [MEDIACTRL] RFC 6917 on Media Resource Brokering X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 23:20:43 -0000 --Apple-Mail=_407DE4F0-7414-4498-BFE5-F8BEDA595D38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii PAR-TAY!!!! Excellent work, all. On Apr 11, 2013, at 5:44 PM, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6917 >=20 > Title: Media Resource Brokering=20 > Author: C. Boulton, L. Miniero, > G. Munson > Status: Standards Track > Stream: IETF > Date: April 2013 > Mailbox: chris@ns-technologies.com,=20 > lorenzo@meetecho.com,=20 > gamunson@gmail.com > Pages: 136 > Characters: 280399 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-mediactrl-mrb-19.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6917.txt >=20 > The MediaCtrl working group in the IETF has proposed an architecture > for controlling media services. The Session Initiation Protocol > (SIP) is used as the signaling protocol that provides many inherent > capabilities for message routing. In addition to such signaling > properties, a need exists for intelligent, application-level media > service selection based on non-static signaling properties. This is > especially true when considered in conjunction with deployment > architectures that include 1:M and M:N combinations of Application > Servers and Media Servers. This document introduces a Media Resource > Broker (MRB) entity, which manages the availability of Media Servers > and the media resource demands of Application Servers. The document > includes potential deployment options for an MRB and appropriate > interfaces to Application Servers and Media Servers. >=20 > This document is a product of the Media Server Control Working Group = of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl --Apple-Mail=_407DE4F0-7414-4498-BFE5-F8BEDA595D38 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJRaGlyAAoJEDY/T2tCIPW3NKcQAIdRH4EeVJLxSvs3uBPA7P+x kzMcSiRIqug65P4vFwgC1uSiZQq6GeJSb9ophBBrLxWo27ZTJwwhiRJcCYQyKXEp yie0eNLwop7jPQSHmjxsfoHz0RuZGSGDo+11lN8igJ3t7a7LYcAL22VPp5xpnJ+8 mcWjg7qDrIKoBvFSwXW8KyyBTp96AbSi4gryMZ6U8wILtEkI4FybeAOjel7fAi2k CVPsI/jEP3nFUDzzhWYLVWz8mh2Ekjb5weFDVQxI5q+0xTr2g3jhlxz7mtDofDmQ hznnR3qlCOtHB3ltf6r2SPFtDZ6qIERrIVB2Av+8mVQ1SCIDRyCaLKSFkDSIyGjd I7xWvxR3RPRA/VyN+NDXzI9YeU8kOjRsk6YI8vkYhQ3Qgru5p884PTp79+DSD8PE t4W0tiXw2ap2mr6h4srPMKUTSfv3wtTp0DcYd3N97yEa3FGpwTGNJ23GEboR9fw5 rymVwD1NW6xcgDgcd1p2RZU3bjtoESGFjR9zyBZLXnSwG0KBB0ucZmonCwcrRXL4 yejlA+gD1etL4b38Mz+gtXjJSDEv1QMT6vZjVQdw6LSuDRVLsHUA0uFPJ2CgzM8r Gy561VTMl78XR7zm8OFFPRBHl8SnroyJyszWlwjpm1EfpYCptgVfYuu9TtS1s5nb 4Cl/5azEIfA+Vi+ikXlJ =NivS -----END PGP SIGNATURE----- --Apple-Mail=_407DE4F0-7414-4498-BFE5-F8BEDA595D38-- From spencer@wonderhamster.org Fri Apr 12 16:31:00 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6164721F8F00 for ; Fri, 12 Apr 2013 16:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0p5kYzTj8ph for ; Fri, 12 Apr 2013 16:30:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5324B21F8F10 for ; Fri, 12 Apr 2013 16:30:58 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net [99.108.174.213]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LsCyV-1UZHec3hYV-013ZiF; Fri, 12 Apr 2013 19:30:56 -0400 Message-ID: <5168992B.20104@wonderhamster.org> Date: Fri, 12 Apr 2013 18:30:51 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eric Burger References: <20130411214409.51DDEB1E003@rfc-editor.org> <0A241228-2798-42D3-B03C-BF896BBC267F@standardstrack.com> In-Reply-To: <0A241228-2798-42D3-B03C-BF896BBC267F@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:AhotvFJuP6zObLZz8KCcqi1Br3XAPWyRk6b9HcLLRhL 940iK18CIpBM155TDuft99b4JdGbPDjvsf+0U1H5LPVYbyG1TJ nD4opgkHQ95nuLSEfmoosXsa2jBjgoZGlC+cGph3in9yfRhwSY WvmUkMOAMhOtvdnTV7OaMqI8SNM4365ifKcj3k9bbKATpEtw91 FylQCmxbMSh+R72QzlmnV1mFKkpRtWysaDvoG4VScW14FhToLe 6gG7zmdZAscQa58zEwS4x/PtAFL6hsqvsgk8mSvsVSBaM8jbUc a9b6gUCeGM0o0s4fLy5qlJyaXBZN1DDy9Qoef1H8e4njQ344kO eQKWkFjH601PmA4FXy0j1KHTiPQN5Tpb3uW9LmlVL Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] RFC 6917 on Media Resource Brokering X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 23:31:00 -0000 On 4/12/2013 3:07 PM, Eric Burger wrote: > PAR-TAY!!!! > > Excellent work, all. > > On Apr 11, 2013, at 5:44 PM, rfc-editor@rfc-editor.org wrote: > >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 6917 >> >> Title: Media Resource Brokering >> Author: C. Boulton, L. Miniero, >> G. Munson >> Status: Standards Track >> Stream: IETF >> Date: April 2013 >> Mailbox: chris@ns-technologies.com, >> lorenzo@meetecho.com, >> gamunson@gmail.com I'd like to add my congrats to Eric's, as a long-ago co-chair ... I know it wasn't easy, and we had an implementation pretty much every step of the way! Spencer From eburger@standardstrack.com Fri Apr 12 23:57:40 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2F221F86B8 for ; Fri, 12 Apr 2013 23:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.477 X-Spam-Level: X-Spam-Status: No, score=-101.477 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, J_BACKHAIR_23=1, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1prxQKLIrTU for ; Fri, 12 Apr 2013 23:57:36 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.237]) by ietfa.amsl.com (Postfix) with ESMTP id C82E921F8648 for ; Fri, 12 Apr 2013 23:57:36 -0700 (PDT) Received: from 1-193.icannmeeting.org ([199.91.193.1]:51985 helo=[10.196.202.183]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UQuOs-0001hd-JI; Fri, 12 Apr 2013 23:57:33 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Eric Burger In-Reply-To: <20121226131152.4660538e@rainpc> Date: Sat, 13 Apr 2013 02:57:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> To: Lorenzo Miniero X-Mailer: Apple Mail (2.1503) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: "mediactrl@ietf.org list mailing" Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 06:57:40 -0000 Are we done yet? On Dec 26, 2012, at 7:11 AM, Lorenzo Miniero = wrote: > Hello Dale, >=20 > first of all, thanks for your detailed review! I'm answering to this > mail first, leaving the extracted issue of the previous issue to = later, > since, as you pointed out, that's a more general issue. >=20 > I've added my replies inline prefixed by a [LM]. >=20 >=20 > On Wed, 19 Dec 2012 15:09:45 -0500 (EST) > worley@ariadne.com (Dale R. Worley) wrote: >=20 >> Review of draft-ietf-mediactrl-call-flows-10 >>=20 >> The first thing that comes to mind is that this is a massive body of >> work, and tremendously useful for the implementer! >>=20 >=20 >=20 > [LM] Thanks! That's exactly what we wanted to achieve. >=20 >=20 >> I've listed the items in the order they appear in the draft. Almost >> all of them are editorial rather than technical. The technical >> questions are: >>=20 >> item 15 (is the listing of control packages in the SDP important or = not) >> item 17 (the negotiation of the timeout value is vague) >> item 35 (mixing of playback of two recordings) >> item 38 (semantics of setgain) >> item 53 (how does AS send media INVITE to the correct MS) >> item 55 (how does the MS know which AS sent each request) >>=20 >> item 1) various >>=20 >> The indentation of the header lines identifying various messages is >> inconsistent. I can find the following lines in various places: >>=20 >> 1. AS -> MS (SIP INVITE) >> A1. AS -> MS (CFW CONTROL, createconference) >> A1. AS1 -> MS (CFW CONTROL, audit IVR) >> 1. AS -> MS (CFW SYNC) >>=20 >> However, it may be easiest to have the RFC Editor fix that by giving >> them an appropriate instruction, as they are likely to manually = adjust >> the indentation of the examples anyway. >>=20 >=20 >=20 > [LM] You're right, the indentation often varies, and the logic behind > this currently is according to whether or not the example fits the = page. > Instructions about this would be welcome! >=20 >=20 >> item 2) various >>=20 >> There are a lot of places where an arrow seems to go from a network >> entity to itself, such as "create conf and its ID" below: >>=20 >> AS MS >> | | >> | 1. CONTROL (create conference) | >> |++++++++++++++++++++++++++++++++>>| >> | |--+ create >> | | | conf and >> | 2. 200 OK (conferenceid=3DY) |<-+ its ID >> |<<++++++++++++++++++++++++++++++++| >>=20 >> However, the event described on the label, "create conf and its ID", >> is not the transmission of a message, and so it doesn't seem like it >> should be represented by an arrow. A more accurate alternative would >> be: >>=20 >> AS MS >> | | >> | 1. CONTROL (create conference) | >> |++++++++++++++++++++++++++++++++>>| >> | | create >> | | conf and >> | 2. 200 OK (conferenceid=3DY) | its ID >> |<<++++++++++++++++++++++++++++++++| >>=20 >=20 >=20 > [LM] Yes, in that case the arrow was not meant as a network = connection, > but as a further step in the sequence diagram, that is what that > CONTROL message triggers in the MS application logic. The same applies > to all the examples where this happens. If you think the arrowless > diagram is clearer to the reader we might remove them: the problem = with > this is that, without arrows, some diagrams might be harder to read, > i.e., in terms of who does what in diagrams with several components > interacting with each other. As an alternative, we might clarify what > those arrows are and what they are not. What do you think about this? >=20 >=20 >=20 >> item 3) section 1 >>=20 >> "self-sustained" should be "self-contained". >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> item 4) section 2 >>=20 >> Note that due to RFC formatting conventions, this document often >> splits SIP/SDP and CFW across lines whose content would exceed 72 >> characters. >>=20 >> "whose content ..." is applied to the wrong referent, a "lines", but >> those lines are the post-split lines, not the pre-split lines. >> Perhaps: >>=20 >> Note that due to RFC formatting conventions, SIP/SDP and CFW lines >> whose content exceeds 72 characters are split across lines. This >> line folding is marked by a backslash at the end of the first line. >> This backslash, the preceding whitespace, the following CRLF, and >> the whitespace beginning the next line would not appear in the >> actual protocol contents. >>=20 >=20 >=20 > [LM] Thanks, we'll change the sentence. >=20 >=20 >> item 5) section 2 >>=20 >> Due to the same 72 characters limitation, this document also >> sometimes splits the content of XML elements across lines: please >> beware that, when this happens, no whitespace is actually meant to >> be neither at the beginning nor at the end of the element content. >>=20 >> This seems to be incorrect, as in many places, an XML *element*, that >> is, everything from the start tag to the end tag (see XML spec, rule >> "element"), is quite long and is necessarily split across lines, but >> is also valid. (However, that interpretation depends on entities >> respecting the common convention that whitespace character content is >> to be ignored if it appears immediately within an element that does >> not admit immediate character content.) >>=20 >> I believe you meant "start tag" instead of "element". But in that >> case, line breaks between the attributes of a start tag are valid in >> XML (see XML spec, rule "STag"). If this is correct, the above >> sentence can be omitted. >>=20 >> However, the message B1 in section 7.1 may be an exception. See the >> appropriate item. >>=20 >=20 >=20 > [LM] We actually added this line after a comment of yours on the MRB > document examples, which exhibited a similar behaviour. Since we = wanted > to clarify that the examples didn't include pre and post whitespaces, > we added the text to make this clearer. If that's unneeded we can > remove the sentence again. >=20 >=20 >> item 6) section 3 >>=20 >> This document makes use of the same terminology as the one that can >> be found in the referenced documents. >>=20 >> This is awkward. Perhaps: >>=20 >> This document makes use of the same terminology as the referenced >> documents [RFC6230] [RFC6231] [RFC6505] [I-D.ietf-mediactrl-mrb]. >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> item 7) section 4 >>=20 >> This section starts with a paragraph over one page long. Could it be >> broken into multiple paragraphs? >>=20 >=20 >=20 > [LM] Did you mean section 4.1? Section 4 starts with just a few lines. >=20 >=20 >> item 8) section 4 >>=20 >> It seems overly complicated to explicitly describe "categories" to >> contain only four things. Also, the text needs to mention that = Figure >> 3 contains *two* diagrams, otherwise the accounting seems to be >> incorrect. Perhaps: >>=20 >> Four diagrams are provided. Two of them (Figure 1 and Figure 2) >> describe normal operation of the framework. Figure 3 contains two >> diagrams describing asynchronous event notifications. Figure 1 >> embraces the MS perspective, whereas Figure 2 is on on the AS side. >> The upper part of Figure 3 shows how events are generated, on the >> MS side, by issuing a CONTROL message addressed to the AS; events >> are acknowledged by the AS through standard 200 responses. Hence, >> the behavior of the AS, which mirrors that of the MS, is depicted >> in the lower part of the figure. >>=20 >=20 >=20 > [LM] Good point, we'll fix this. >=20 >=20 >> item 9) section 4 figure 1 >>=20 >> I think the state machine could be clarified: >>=20 >> - Replace the event "API 200" in "API 200/200" with "API terminate", >> which is how the API termination is described on other arcs. >>=20 >> - Replace the event "API 202" in "API 202/202" with "API update", >> which is how the API non-termination is described on other arcs. >>=20 >> - Further, change "API update" to "timer" or something like that, to >> indicate that the MS CFW state machine must generate a 202 *based on >> the passage of time*, not based on the API providing some sort of >> "update". If these time intervals are globally fixed for the CFW >> protocol, their fixed values could be written in. >>=20 >=20 >=20 > [LM] Ok, we'll make this clearer. >=20 >=20 >> - The states "'202' sent" and "'update' sent" have the same outgoing >> transitions, so they should probably be merged. >>=20 >=20 >=20 > [LM] I'm not sure about this: 202 is only sent after the first CONTROL > message to tell the AS it may take a while to process the request, = after > which you can either have further 202 messages should the processing > take even more time, or one or more UPDATE messages related to that > CONTROL request after that. They're two different messages in the > protocol semantics. Nevertheless, it's also true that, according to > RFC6230, a 202 is basically a pre-REPORT message... any feedback on > this? >=20 >=20 >> - Is there truly an "Error" message that is comparable to the "200" >> and "202" messages? Or is sending "Error" a shorthand for a cluster >> of numeric response codes? If the latter, it would help to make >> that clearer here in the introductory material. >>=20 >=20 >=20 > [LM] Yes, errors are numeric codes (Section 7. in RFC6230). We'll fix > the text. >=20 >=20 >> - What happens if the API detects an error after 202 has been sent? >> There is no "API Error" arc from "'202' sent"/"'update' confirmed". >>=20 >=20 >=20 > [LM] Good point. The idea is that, once the MS sends a 202, the = request > has been correctly processed, and so is supposed to be fine as far as > the protocol is concerned. I guess there could be circumstances when = an > errors occurs after that, e.g., in retrieving an audio file to be = played > to a UAC: in that case, the AS would be informed of the termination of > the dialog/request in a REPORT terminate, including details on the = issue > which are Control Package specific. Do you think explaining this in = the > text may help readers? >=20 >=20 >> item 10) section 4 figure 2 >>=20 >> Clarifications of the state machine: >>=20 >> - There is no "Error" arc from the "202 received" and "'update'" >> states. Are errors impossible here? >>=20 >> - The states "202 received" and "'update'" have the same outward arcs >> and so could be merged. >>=20 >> - The two figures are inconsistent regarding whether response numbers >> (200, 202) are within quotes '...'. >>=20 >> - The two figures are inconsistent regarding whether report = categories >> (update, terminate) are within quotes '...'. >>=20 >> - The two figures are inconsistent regarding whether the sending of a >> request or response in an arc's label is indicated using "send" or >> not. >>=20 >> item 11) section 4 figure 3 >>=20 >> There are similar inconsistencies between figure 3 and figures 1 and = 2. >>=20 >> item 12) section 5 >>=20 >> The term "COMEDIA" is used, and a reference is given to RFC 4145. = But >> that RFC does not use the term "COMEDIA" at all. The framework I-D >> also uses "COMEDIA" without explicitly defining it. It would be >> helpful to insert here a definition of "COMEDIA", which seems to be >> synonymous with "media of type application/cfw". >>=20 >=20 >=20 > [LM] I thought COMEDIA actually came from RFC4145, standing for > "connection-oriented media". Even the MSRP RFC refers to it that way. = If > that's incorrect or incomplete we'll fix this in the next version. >=20 >=20 >> item 13) section 5.1 >>=20 >> If the request is fine, the MS answers with its own offer, >>=20 >> shouldn't this be: >>=20 >> If the request is fine, the MS answers with its answer, >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> item 14) section 5.1 >>=20 >> The MS replies with the list of packages it supports, by >> adding a dummy example package to the list provided by the AS. >>=20 >> The "by" should be removed, as the replying is not done "by adding"; >> instead, the MS replies and also adds. >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> item 15) section 5.1 >>=20 >> It is worth noting that this exchange of information is not meant >> as a strict or formal negotiation of packages: in case the AS >> realizes that one or more packages it needs are not supported >> according to the indications sent by the MS, it may, or may not, >> choose not to open a control channel with the MS at all, if its >> application logic leads to such a decision. The actual negotiation >> of control packages is done subsequently through the use of the >> framework SYNC transaction. >>=20 >> This confuses me: Either the list of packages in the SDP = offer/answer >> is significant or it is not. If it is not, why is it provided? >>=20 >> In particular, if the MS may support packages that it does not admit >> to in the answer, then when the AS sees an answer that does not >> contain the needed packages, it will have to continue with the = control >> channel connection in order to determine if the MS *actually* = supports >> the needed packages or not. Thus, the MS could omit all ctrl-package >> attributes in its answers all the time. >>=20 >> Also, it's not clear whether the AS is required to provide the list = of >> packages it will need. If it is required, then the SDP can be used = to >> choose the correct MS based on MS capabilities. If it is not >> required, a different architectural mechanism is needed. >>=20 >=20 >=20 > [LM] That section refers to a draft Chris submitted to the MMUSIC WG > some time ago: >=20 > = http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attrib= ute-07 >=20 > so any clarification about the purpose and constraints of such a > mechanism should be addressed in the specification. Chris, do you = think > this behaviour could be clarified in the draft, in order to have it > reflected in the Call Flows as a consequence? >=20 >=20 >> item 16) section 5.3 >>=20 >> Whether "keep alive" is hyphenated is not consistent. >>=20 >=20 >=20 > [LM] The right word is "keep-alive", we'll make this consistent. >=20 >=20 >> item 17) section 5.3 >>=20 >> In the previous section it has been described how a timeout value = for >> the keep alive mechanism is negotiated. Specifically, in the = example >> the AS and the MS agreed on a value of 100 seconds. =20 >>=20 >> In fact, that section does not describe how the value is negotiated >> (since it is not clear what happens if the MS dislikes the value >> proposed by the AS). However, this is correct: >>=20 >> In example in the previous section, the AS and the MS agreed on a >> value of 100 seconds. >>=20 >=20 >=20 > [LM] According to RFC6230, the 200 to the SYNC MUST have the same > keep-alive value proposed in the original SYNC. Who sends the SYNC can > change according to the COMEDIA negotiation. Specifically, "The = previous > steps ensure that the entity initiating the Control Channel connection > is always the one specifying the keep-alive timeout period.". So, to > answer your question, I guess that if a MS dislikes the value, it can > just pick the active role and send a new SYNC with a new keep-alive > value. >=20 >=20 >>=20 >> item 18) section 6 >>=20 >> Besides, unless stated otherwise, the same UAC session is = referenced >> in all the above mentioned examples. >>=20 >> Is "above mentioned" the correct modifier? The previous paragraph >> refers to "the following scenarios". >>=20 >=20 >=20 > [LM] You're right, it's a bit unclear, we'll fix this. >=20 >=20 >> item 19) section 6 figure 10 >>=20 >> It would be useful at this point to make it clear that the two = INVITEs >> are different SIP dialogs (as these scenarios are constructed). (Or, >> if the AS may be inline and acting as a proxy, describe that there = may >> be two dialogs or only one.) Including, replace the second "INVITE >> (X)" with "INVITE (Y)" to show that the URIs need not be the same. >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> Also, why not include the establishment of the Control Channel in the >> figure, as that will not need to be duplicated in any further figure. >>=20 >=20 >=20 > [LM] It's not there as the Control Channel may already have been > negotiated and synced in advance. That is, the AS may be redirecting > calls to a MS it has already been already "talking with" for a while. > We explained this at the beginning of the section, "All the examples > assume that a Control Channel has already been correctly established > and SYNCed between the reference AS and MS", as that was already > addressed in the previous section. >=20 >=20 >> item 20) section 6 figure 11 >>=20 >> Figure 11 appears to be only a caption. Or is it the SIP signaling? >> Expositions of protocol messages are rarely considered to be figures. >>=20 >=20 >=20 > [LM] You're right, we made use of figures to simplify the formatting > of the messages, we'll remove te caption. >=20 >=20 >> item 21) section 6 >>=20 >> The phrase "These three identifiers" is confusing because the text = has >> just introduced four identifiers. >>=20 >=20 >=20 > [LM] Oops, right. >=20 >=20 >> I assume that if the SDP from AS to MS also contains label = attributes, >> the Mediactrl framework specifies how they will be used (or ignored), >> so that the "addressing" of media streams is not made ambiguous. >>=20 >> item 22) section 6.1.2 >>=20 >> The 202+REPORT(s) mechanism is used whenever the MS wants to tell >> the AS that the requested operation might take some more time than >> expected. >>=20 >> This is probably incorrect. What you mean is, "the requested >> operation might take more than *** seconds". The fixed or variable >> time limit should be specified here. >>=20 >=20 >=20 > [LM] Actually, the time is Control Package dependent. Different = packages > may have different timeouts. Quoting the framework, "A Control Package > MUST explicitly define the circumstances under which the server sends > 200 and 202 messages." >=20 >=20 >> In this example, the preparation ends before the >> timeout, and so the transaction is concluded with a 'REPORT >> terminate', which acts as the 200 message in the previous example. >>=20 >> The last clause is rather confusing, as 'REPORT terminate' is a >> request, not a response, and thus doesn't "act like" a 200 message. >> Perhaps: "which reports the end of the transaction (as did the 200 >> message in the previous example)". >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> item 23) section 6.2 figure 18 >>=20 >> It might be useful to distinguish the four(?) SIP dialogs involved. >>=20 >=20 >=20 > [LM] Do you mean as in different figures? or clearer text? >=20 >=20 >> item 24) section 6.2.2 >>=20 >> Three hours is 10,800 seconds, not 1,800 seconds. I think the = easiest >> fix is to replace "3 hours" with "30 minutes". >>=20 >=20 >=20 > [LM] Oops, ugly typo, will fix this (and good thing my math teacher is > not reading this :-) ) >=20 >=20 >> RFC 6230 section 6.2 >>=20 >> An entity acting as a Control Server, on receiving a request, MUST >> generate a response [...]. The response MUST conform to the ABNF >> Responses MUST NOT include the 'Status' or 'Timeout' message >> headers, [...] >>=20 >> RFC 6230 section 6.3.2.1 >>=20 >> A Control Server issuing a 202 response MUST ensure the message >> contains a 'Timeout' message header. >>=20 >> item 25) section 6.2.3 >>=20 >> This section is rather difficult to follow. I'm not sure why, but >> partly it's because the text doesn't rigorously make clear what = events >> are "before", that is, when the two audio channels of the original >> conference are being recorded, and "after", when the two recordings >> are being played back. For instance, in the second paragraph, the = last >> sentence is "after", but the first two sentences are "before". >> Instead, there should be a paragraph break there, and starting = "Later, >> when we desire to play the whole conversation to UAC, the AS may >> take...". >>=20 >=20 >=20 > [LM] You're right, we'll try to make this clearer. >=20 >=20 >> It would help if the UAC which is listening to the playback was = called >> "UAC3" or something like that, as "UAC" is also a generic term, and >> it's not immediately clear that it is unrelated to UAC1 and UAC2. >>=20 >> It would also help if the two *recordings* had names different from >> the UACs during the recording. In particular "play UAC1 on confY" is >> hard for the naive reader to understand until he realizes that "UAC1" >> means the recording file of the audio generated by UAC1. >>=20 >=20 >=20 > [LM] Good points. >=20 >=20 >> item 26) section 6.3 >>=20 >> o The AS invokes the creation of a new conference instance by = means >> of a CONTROL request (1); this request is addressed to the >> conferencing package (msc-mixer/1.0) and contains in the body = the >> directive (createconference) with all the desired settings for = it; >>=20 >> The antecedent of "it" is not particularly clear. The antecedent is >> "a new conference", which is the 6th preceding noun phrase, which is >> only determined because it is the first preceding noun phrase which >> has settings. Better to say "... the desired settings for the new >> conference instance". >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> item 27) section 6.3.1 figure 30 >>=20 >> This figure uses "UAC1" and "UAC2", but the other figures in 6.3 use >> "UAC A", "UAC B", and "UAC C". Ditto for figure 31 and some of the >> text. >>=20 >=20 >=20 > [LM] Nice catch, we'll fix this. >=20 >=20 >> item 28) section 6.3.4 figure 38 >>=20 >> The notation "D+[a+c]" is clever, but "D+(A+C)/2" would be more >> accurate. (And see the following item regarding the volume level.) >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> item 29) section 6.3.4 >>=20 >> The volume level at which the main conference is heard in the sidebar >> is not stated consistently: >>=20 >> the main conference. The mix of the conference, instead, must be >> attached to the sidebar, but with a lower volume (50%), being just = a >> background to the actual conversation. This would allow both B and = D >>=20 >> 2. then, the main conference mix is attached to it as 'sendonly' = and >> with a -5dB gain to limit the volume of its own contribution to >> 30% (so that B and D can hear each other louder, while still >> listening to what's happening in the main conference in >> background); >>=20 >> | | | B1. CONTROL (join confX-->confY) | >> | | |++++++++++++++++++++++++++++++++>>| >> | | | |--+ join = confX >> | | | | | & confY >> | | | B2. 200 OK |<-+ sendonly >> | | |<<++++++++++++++++++++++++++++++++| (50% = vol) >>=20 >> >> >> >> >> >> >> >>=20 >> Of these, two references say 50% (-3dB) and two references say 30% or >> -5dB. >>=20 >=20 >=20 > [LM] You're right, we'll make this consistent. >=20 >=20 >> item 30) section 6.3.5 figure 43 >>=20 >> Is it intended that UAC (FCC) does not have any RTP going to the MS? >> (Indeed, is it necessarily a UAC? But perhaps SIP is needed to set = up >> BFCP.) >>=20 >=20 >=20 > [LM] Yes, to clarify the distinction between a simple participant and = a > chair we chose to only display RTP for the participant, with the chair > moderating what happens on it. Whether or not the FCC has any RTP > flowing is not relevant to the example and that's why we omitted it. > That said, the chair does not need to be a UAC, you're right, and SIP = is > not mandated to set up BFCP (RFC4583 is only a way to do so, BFCP just > talks of out of band mechanisms generally). We will remove the UAC for > the FCC in the figure to make this clearer. >=20 >=20 >> item 31) section 6.3.5 >>=20 >> The participant UAC is labeled inconsistently as "UAC", "UAC (FCP)", >> and "UAC1". ("UAC" may be correct, as the context for that term my = be >> describing a generic or abstract UAC.) Similarly, "UAC (FCC)" and >> "UAC2" are used for the chair UAC. >>=20 >=20 >=20 > [LM] We'll fix the diagrams accordingly. >=20 >=20 >> item 32) section 6.3.5 >>=20 >> It might be desirable to mention that the previous speaker should be >> muted before UAC1 can be un-muted. Usually, this muting will happen >> between the Accepted and Granted BFCP messages, so it probably should >> be illustrated in the sequence of events. >>=20 >=20 >=20 > [LM] That's actually not needed, as BFCP does not force an exclusive > access to the resources it moderates. According to the policy in use, > several participants may be granted the same resource (e.g., ability = to > talk) at the same time (e.g., in a conference bridge). >=20 >=20 >> item 33) section 6.4 >>=20 >> It might be helpful to expand "VCR" the first time it is used. >> (Apparently it does not mean "video cassette recorder", and I see no >> suitable meaning on the Wikipedia "disambiguation" page for "VCR".) >>=20 >=20 >=20 > [LM] We borrowed this terminology from RFC6231, the IVR Control = Package. > The idea is to have "video cassette recorder"-lie controls, right, = like > the ability to play, pause, stop, rewind, etc. We'll expand this. >=20 >=20 >> item 34) section 6.4.2 >>=20 >> In fact, >> rather than having the AS build different framework messages >> according to the current time to build an announcement,=20 >>=20 >> This is difficult to read. Perhaps >>=20 >> In fact, rather than having the AS build an announcement according >> to the current time using different framework messages, >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> item 35) section 6.4 >>=20 >> The discussion of mixing in the background music should be contrasted >> with the mixing of the two recordings during playback in section >> 6.2.3. Naively, it would seem that the same mixing techniques could >> be used in both cases, but the two sections implement mixing in >> entirely different ways. >>=20 >=20 >=20 > [LM] Are you talking of 6.4.2 (current time example)? If so, this was > done on purpose, to exploit two different scenarios to showcase the = use > of two different techniques. You're right in saying that the same = could > be applied to both cases, nothing naive in this :-) >=20 >=20 >> item 36) section 6.4.3 >>=20 >> An example contains XML elements that seem to be unnecessarily >> complex: >>=20 >> >> >> * >> >> >> >>=20 >> As far as I can tell from the SRGS specification, functions >> more-or-less as a type of parenthesis, and is needed only when (1) a >> "weight" or "repeat" attribute needs to be applied to the group, (2) >> delimiting one alternative of a element, or (3) constructing >> the "null" regular expression (that consumes no input and always >> matches). Thus, these examples can be simplified to: >>=20 >> >> * >> >> >>=20 >> Then again, if the example is taken from a real interaction, perhaps >> it is best to leave it as it really happened. >>=20 >=20 >=20 > [LM] I'm not an expert of SRGS, so I'm not sure about this. This is = how > we implemented it in our Media Server, and it works this way, but it > would be nice to hear from other implementers to see if they usually > realize similar scenarios in a different way! >=20 >=20 >> item 37) section 6.4.3 >>=20 >> to implement is a , and we are only interested in two- >> digits DTMF strings (maxdigits); the AS is not interested in a >>=20 >> "two-digits" should be "two-digit". (Because this phrase is used as = a >> modifier of "DTMF strings", the "digit" is not plural.) >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> instructs the MS into modifying the volume of the = UAC-->conference >>=20 >> "into modifying" would better be "to modify". >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> audio flow (setgain=3D-5dB sendonly); notice how the request = also >>=20 >> This is probably intended to be "-3dB", as all other uses of setgain >> in this section (including the displayed messages) use a 3 dB >> increment. >>=20 >=20 >=20 > [LM] Right, we0ll make this consistent. >=20 >=20 >> item 38) section 6.4.3 >>=20 >> This section leads to a question about the semantics of the > controltype=3D"setgain" ...> operation: Clearly, initially the = stream >> is output at the same volume as the input media. But when "> controltype=3D'setgain' value=3D'+1'>" is applied, does that cause = the >> stream's output volume to be set to +1 dB *relative to the input >> media* or to +1 dB *relative to the previous volume setting*? >>=20 >> E.g., if I apply that operation twice, does the second application >> leave the amplification at +1 dB or raise it to +2 dB? >>=20 >> The examples in section 6.4.3 suggest the second interpretation. >>=20 >> The text in draft-ietf-mediactrl-mixer-control-package-14 is not = clear >> on this point: "setgain" is only discussed in section 4.2.2.5.1, and >> it says "use the value of the "value" attribute as a specific gain >> measured in dB to apply". That would be most likely to mean "as a >> specific gain measured in dB to apply to the input", which suggests >> the first interpretation. >>=20 >> In any case, the semantics of this need to be clarified and the >> example adjusted accordingly. >>=20 >=20 >=20 > [LM] If I recall correctly, when we first implemented this we = discussed > it with the IVR authors during a meeting. If I'm not wrong the > conclusion was that setgain *sets* the gain, and does not modify the > previous value. I don't have the MS code in front of me right now, > though, I'll have to double check how we implemented this and let you > know. >=20 > IVR authors, any insight on this from a specification point of view? >=20 >=20 >> item 39) section 7.1 >>=20 >> Each MS makes use of the publishing interface to provide an MRB = with >> relevant information. >>=20 >> In the relationship between the MRB and MS, the MRB initiates the >> relationship. Thus, it would be clearer to express this: >>=20 >> An MRB makes use of the MS's publishing interface to acquire >> relevant information. >>=20 >> It is >> enough to point out that, in this case, the MRB adds a new voice to >> the 'Packages' it needs support for (mrb-publish/1.0). >>=20 >> "voice" should be "item". >>=20 >> All >> this messages flow through the control channel as all the messages = in >> ---^^^^ >> should be "these" >> ----------------------------------------------------^ >> insert "do" >> this document. >>=20 >=20 >=20 > [LM] Ok. >=20 >=20 >> item 40) section 7.1 message B1 >>=20 >> This seems to be the only place in the draft where whitespace has = been >> introduced where character content is valid, and so there is a >> question whether the draft needs to indicate that the whitespace = would >> not be present on the wire. The relevant elements are: >>=20 >> >> >> >> nbest >> >> >> >> >> single-view >> >> >> dual-view >> >> >> dual-view-crop >> >> >> dual-view-2x1 >> >> >> dual-view-2x1-crop >> >> >> quad-view >> >> >> multiple-5x1 >> >> >> multiple-3x3 >> >> >> multiple-4x4 >> >> >> >>=20 >> I'm not sure if the schema defining = urn:ietf:params:xml:ns:mrb-publish >> indicates that the whitespace before and after the mixing mode names >> is to be ignored. But this might be a place to use the >> backslash-line-folding convention specified in section 2: >>=20 >> >> >> \ >> nbest \ >> >> >> >> \ >> single-view \ >> >> \ >> dual-view \ >> >> \ >> dual-view-crop \ >> >> \ >> dual-view-2x1 \ >> >> \ >> dual-view-2x1-crop \ >> >> \ >> quad-view \ >> >> \ >> multiple-5x1 \ >> >> \ >> multiple-3x3 \ >> >> \ >> multiple-4x4 \ >> >> >> >>=20 >=20 >=20 > [LM] Yes, as I anticipated, we added that text to reflect a similar > comment you made when reviewing the MRB draft. This fix you suggest > makes sense, so we'll add it to the draft. >=20 >=20 >> item 41) section 7.1, section 7.2, section 7.2.1 >>=20 >> In the Inline mode, instead, the MRB is in the >> path between the AS and the pool of MSs it is handling. >>=20 >> Anyway, the MRB is also >> conceived to work with ASs that are unaware of its functionality, >>=20 >> and the SIP addresses of the chosen MSs. >>=20 >> Generally, "AS" and "MS" are used as the plurals of "AS" and "MS", = but >> in these instances, "ASs" and "MSs" are used. >>=20 >=20 >=20 > [LM] You're right, I fixed this in the MRB and not here, sorry. = Besides, > ASs sounds really bad... :-) >=20 >=20 >> item 42) section 7.1 >>=20 >> request itself and an SDP related to related to either the creation >> -----------------------------^^^^^^^^^^^^^^^^^^^^^ >> "related to" is duplicated. >>=20 >> item 43) section 7.2.1 >>=20 >> MS the MRB has deemed better capable to fulfill the AS = requirements), >> -------------------------^^^^^^ >> This should be "best". >> -------------------------------------------------------^^ >> This should be "AS's" or "AS'" (depending on which spelling = convention >> we are using). >>=20 >> targeting the request, and as a consequence picks up two MS = which >> --------------------------------------------------^^^^^^^^ >> I think you want "picks" here. >>=20 >> after the Query the AS<->interaction becomes 1:1, UAC media dialogs >> ----------------------------^ >> Something appears to be missing here. >>=20 >=20 >=20 > [LM] We'll fix them all. >=20 >=20 >> item 44) section 7.2.2.1, section 7.2.2.2, section 7.2.3 >>=20 >> I think it would make the diagrams a little easier for the naive >> reader to follow if the media types specified in the SDP of the >> message bodies were given. E.g., if an INVITE or 200 carries an >> application/sdp body for audio media, that is shown on the diagram. >> This would be particularly helpful in 7.2.3, where it takes the = reader >> more consideration to deduce what the media types must be. Updated = in >> this way, the diagrams are as follows. (But this has removed the >> comments noting where the SDP has been copied from one message to >> another. That may need to be improved.) >=20 >=20 > [LM] Ok, we'll try and improve this to make it clearer. >=20 >=20 >>=20 >> 7.2.2.1. Inline-aware Mode: CFW-based approach >>=20 >> AS MRB MS >> | | | >> | 1. INVITE | | >> | (multipart/mixed: | | >> | audio, | | >> | application/mrb-consumer+xml) | >> |---------------------->| | >> | 2. 100 (Trying) | | >> |<----------------------| | >> | |--+ Extract SDP and | >> | | | MRB payloads; handle | >> | |<-+ Consumer request to | >> | | pick MS | >> | | | >> | | 3. INVITE | >> | | (audio) | >> | |-------------------------->| >> | | 4. 100 (Trying) | >> | |<--------------------------| >> | | |--+ Negotiate >> | | | | CFW = Control >> | | |<-+ Channel >> | | 5. 200 OK | >> | | (audio) | >> | |<--------------------------| >> | | 6. ACK | >> | |-------------------------->| >> | Prepare new +--| | >> | payload with | | | >> | SDP from MS and +->| | >> | Consumer reply | | >> | | | >> | 7. 200 OK | | >> | (multipart/mixed: | | >> | audio, | | >> | application/mrb-consumer+xml) | >> |<----------------------| | >> | 8. ACK | | >> |---------------------->| | >> | | | >> |--+ Read Cons. reply | | >> | | and use SDP to | | >> |<-+ create CFW Chn. | | >> | | | >> | | >> |<<############## TCP CONNECTION #################>>| >> | | >> | CFW SYNC | >> |++++++++++++++++++++++++++++++++++++++++++++++++++>| >> | | >>=20 >> 7.2.2.2. Inline-aware Mode: Media dialog-based approach >>=20 >> UAC AS MRB = MS >> | | | = | >> | 1. INVITE | | = | >> | (audio) | | = | >> |-------------->| | = | >> | 2. 100 Trying | | = | >> |<--------------| | = | >> | | 3. INVITE | = | >> | | (multipart/mixed: | = | >> | | audio, | = | >> | | application/mrb-consumer_xml) = | >> | |---------------------->| = | >> | | 4. 100 (Trying) | = | >> | |<----------------------| = | >> | | |--+ Extract SDP and = | >> | | | | MRB payloads; handle = | >> | | |<-+ Consumer request to = | >> | | | pick Media Servers = | >> | | | = | >> | | | 5. INVITE = | >> | | | (audio) = | >> | | = |------------------------->| >> | | | 6. 100 (Trying) = | >> | | = |<-------------------------| >> | | | = +--| >> | | | Handle media dialog | = | >> | | | (connection-id) = +->| >> | | | = | >> | | | 7. 200 OK = | =20 >> | | | (audio) = | >> | | = |<-------------------------| >> | | | 8. ACK = | >> | | = |------------------------->| >> | | Prepare new +--| = | >> | | payload with | | = | >> | | SDP from MS and +->| = | >> | | Consumer reply | = | >> | | | = | >> | | 9. 200 OK | = | >> | | (multipart/mixed: | = | >> | | audio, | = | >> | | application/mrb-consumer+xml) = | >> | |<----------------------| = | >> | | 10. ACK | = | >> | |---------------------->| = | >> | | | = | >> | |--+ Read Cons. reply | = | >> | | | and send SDP | = | >> | |<-+ back to UAC | = | >> | 11. 200 OK | | = | >> | (audio) | | = | >> |<--------------| | = | >> | 12. ACK | | = | >> |-------------->| | = | >> | | | = | >> |<<*************************** RTP = ******************************>>| >> | | | = | >> | |--+ Negotiate | = | >> | | | CFW channel | = | >> | |<-+ towards MS | = | >> | | (if needed) | = | >> | | | = | >> | |<<############## TCP CONNECTION = ################>>| >> | | = | >> | | CFW SYNC = | >> | = |+++++++++++++++++++++++++++++++++++++++++++++++++>| >> | | = | >>=20 >> 7.2.3. Inline-unaware Mode >>=20 >> AS MRB MS >> | | | >> | 1. INVITE | | >> | (application/cfw) | | >> |---------------------->| | >> | 2. 100 (Trying) | | >> |<----------------------| | >> | |--+ Pick a MS | >> | | | and redirect | >> | |<-+ INVITE there | >> | | | >> | | 3. INVITE | >> | | (application/cfw) | >> | |-------------------------->| >> | | 4. 100 (Trying) | >> | |<--------------------------| >> | | |--+ Negotiate >> | | | | CFW = Control >> | | |<-+ Channel >> | | 5. 200 OK | >> | | (application/cfw) | >> | |<--------------------------| >> | | 6. ACK | >> | |-------------------------->| >> | | | >> | 7. 200 OK | | >> | (application/cfw) | | >> |<----------------------| | >> | 8. ACK | | >> |---------------------->| | >> | | | >> | | >> |<<############## TCP CONNECTION #################>>| >> | | >> | CFW SYNC | >> |++++++++++++++++++++++++++++++++++++++++++++++++++>| >> | | >>=20 >> item 45) section 7.2.2 >>=20 >> An AS willing to issue a Concumer request by means of SIP, has to = do >> ----------------------------^ >> This should be "Consumer". >>=20 >> envisages two kind of SIP dialogs a Consumer request may be sent >> -----------------^ >> This should be "kinds". >>=20 >> setup a control channel) or a UAC media dialog (a SIP dialog the AS >> ---^ >> This should be "set up". ("set up" functions like a verb; "setup" >> functions like a noun.) >>=20 >> The behaviour in the two cases, which are called respectively CFW- >> -------^ >> Probably better to say "behaviours" here. >> based and Media dialog-based approach, is only slightly different, >> ------------------------------------------^ >> Use "are", to go with "behaviors". >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> item 46) section 7.2.2.1, section 7.2.2.2 >>=20 >> Please note that, to ease the reading of the protocol contents, a >> simple '=3D_Part' is used whenever a boundary for a = 'multipart/mixed' >> payload is provided, instead of the actual boundary that would be >> inserted in the SIP messages. >>=20 >> This seems like a poor strategy, as the resulting figures are not >> strictly correct. Perhaps use "Part" as the boundary value, which >> would result in figures that look like the following, which strictly >> correct and are just as easy to read: >>=20 >> [..] >> Content-Type: multipart/mixed;boundary=3D"Part" >>=20 >> --Part >> Content-Type: application/sdp >>=20 >> v=3D0 >> o=3D- 2890844526 2890842807 IN IP4 as.example.com >> [...] >>=20 >> --Part >> Content-Type: application/mrb-consumer+xml >>=20 >> >> > xmlns=3D"urn:ietf:params:xml:ns:mrb-consumer"> >> [...] >> >>=20 >> --Part-- >>=20 >=20 >=20 > [LM] I think we did it this way after a comment received on the list: > Chris and I did the same for the examples in the MRB draft, for = instance. > If you think it might improve the readibility of the document we'll > change this. >=20 >=20 >> In both of these sections, just before the message listings, there is >> a line containing only: >>=20 >> o >>=20 >=20 >=20 > [LM] Probably a leftover, we'll remove it. >=20 >=20 >> In the following message titles, "SDP" appears in lower case: >>=20 >> section 7.2.2.1: >> 3. MRB -> MS (INVITE sdp only) >> 5. MRB <- MS (200 OK sdp) >> section 7.2.2.2: >> 5. MRB -> MS (INVITE sdp only) >> 7. MRB <- MS (200 OK sdp) >> 11. UAC <- AS (200 OK sdp) >>=20 >> item 47) section 7.2.3 >>=20 >> pick a MS rather than another. >> --------^ >> Probably should be "one", to contrast with "another". >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> item 48) section 7.2.3 >>=20 >> This example does not give the content of the messages, unlike the >> previous two examples. >>=20 >=20 >=20 > [LM] It's because in the IUMM mode no Consumer transaction is = involved. > It's a normal RFC6230 Control Channel negotiation where the MRB acts > as an intermediary, that is, picking a MS for the AS according to some > logic. In this case, in fact, the AS does not support the MRB > specification, and so just tries to set up a control channel the way > it knows. >=20 >=20 >> item 49) section 7.3.1 >>=20 >> This section is titled "Query/IAMM". The call flow does mesh with = the >> call flow in section 7.2.1, "Query Mode", but it does not mesh with >> the call flow in section 7.2.2.1, "Inline-aware Mode: CFW-based >> approach" nor with the call flow in section 7.2.2.2, "Inline-aware >> Mode: Media dialog-based approach". >>=20 >> It would probably be best to change the title of the section to >> "Query". If necessary, an additional section should be added giving >> examples relevant to inline-aware mode. >>=20 >> item 50) section 7.3.1, section 7.3.2 >>=20 >> The use of "IAMM" and "IUMM" is a bit opaque here, as those acronyms >> are not explicitly expanded anywhere in this document. They seem to >> mean what is called "inline-aware mode" and "inline-unaware mode", = but >> the acronyms of those phrases aren't the same as the acronyms used. >>=20 >> Perhaps these section titles could be changed to resemble those of >> 7.2.*, "7.3.1. Query and Inline-aware Mode" and "7.3.2. = Inline-unaware >> Mode". That doesn't fix the problem with the acronyms per se but = does >> make the titles clearer. >>=20 >=20 >=20 > [LM] You're right about both comments, we'll try to make this clearer > and more consistent across the document. >=20 >=20 >> item 51) section 7.3.1 >>=20 >> We might want to mention that in this scenario, the AS obtains >> assignment of an MS *before* any UAC makes a request, in order to = have >> facilities to satisfy future SIP requests. That is probably how AS's >> operate in practice, but a naive reader might expect that the AS will >> make the consumer request only after the AS receives a demand for its >> services. >=20 >=20 > [LM] Actually both Fig.53 and 54 show the AS creating a control = channel > before receiving an INVITE from the UAC. Or was your point about a > different aspect? >=20 >=20 >>=20 >> Nevertheless, there are cases when having an MRB in the signalling >> path ... >>=20 >> You might want to say "the SIP signalling path" here. By my count, >> there are *three* different signalling paths: the COMEDIA = negotiation >> (INVITE with application/cfw SDP), the CFW connection, and the SIP >> signalling (INVITE with audio/etc. SDP). >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> item 52) section 7.3.2 >>=20 >> As mentioned previously, in such a case the AS would interact with >> What case is "in such a case"? (This is the first sentence of a >> section.) It seems that this paragraph is trying to contrast "such a >> case" with "IUMM", but it's not clear what is going on. >>=20 >=20 >=20 > [LM] It's referring to the case described by the section title, which = is > a poor editing choice. We'll make this more explicit. >=20 >=20 >> That said, the IUMM case is also very interesting with respect to = the >> media dialogs management. In fact, in the MRB-unaware mode there >> ---------^ >> This should be "dialog". >=20 >=20 > [LM] OK. >=20 >=20 >> would be no Consumer request and an AS would actually see the MRB = as >> an MS. This means that, unlike the previous scenarios, there is >> actually no choice, meaning the MRB would likely be in the = signaling >> ------------^ >> What is there "no choice" of? The obvious choice is that of a MS, = but >> the MRB clearly can choose which MS to sent the request to. >=20 >=20 > [LM] Probably a poorly translated sentence, as this makes more sense = in > Italian. The sentence is trying to say that there is no active = selection > process driven by an AS<->MRB interaction so yes, something eventually > leading to choosing a specific MS according to that. That's why the > document then explains a potential approach to take care of this. >=20 >=20 >> path anyway. The MRB could either redirect the AS to a MS directly >> or transparently act a proxy/B2BUA and contact a MS (according to >> implementation-specific policies) on behalf of the unaware AS. >>=20 >> To overcome the scalability limitations of such an approach, the MR >> --------------------------------------------------------------^ >> You should add here "at least in regard to the MRB being in the SIP >> signalling path for all calls" -- as far as I can tell, this is the >> only scaling problem this approach removes. (The major one is that >> all calls handled by the AS have to be handled by only one MS.) >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> Rather than recurring to explicit redirection, or always >> ---------------^ >> This isn't the right word. Perhaps "resorting" was intended? >>=20 >=20 >=20 > [LM] Yes, we'll fix this. >=20 >=20 >> item 53) section 7.3.2 >>=20 >> While apparently not a problem, this raises an issue when the same >> unaware AS has several sessions with different MS: the AS would = only >> see one "virtual" MS (the MRB) and so it would relay all calls = there, >> making it hard for the MRB to understand where these media dialogs >> should belong: specifically, whether the UAC calling belongs to the >> AS application logic leading to MS1 or MS2, or wherever else. >>=20 >> This seems to be a deficiency in the CFW protocol: If the AS >> establishes a CFW channel with the MS (via a SIP URI to an MRB), and >> then later the AS wants to addresses a SIP INVITE to the MS, it has = no >> choice but to use the same SIP URI (which routes to the MRB). This >> makes it impossible for the MRB to associate the SIP INVITE with the >> CFW connection, and thus it is difficult for the MRB to route the >> INVITE to the same MS. >>=20 >> What seems to be needed is for either the COMEDIA response >> (application/cfw) or CFW connection to provide a SIP URI that is the >> "real" SIP URI of the far-end of the CFW channel. >>=20 >> Actually, this seems to be a problem even if an AS is addressing an = MS >> URI, but the URI resolves to a redundant set of MSs: There seems to >> be no way to ensure that when a CFW channel is established that a >> subsequent SIP INVITE can be sent to the same MS. This issue seems = to >> be discussed in RFC 6230 section 3, but I can't find any solution >> there. >>=20 >=20 >=20 > [LM] The way it works now is that, for a specific MS, the same SIP URI > is used for both negotiating a control channel and attaching media > dialogs, yes. A way to overcome this may having the MS redirect media > dialogs to a different SIP URI when it receives them (that is, treat > control and media dialogs differently) but I realize how this sounds > like an implementation hack rather than a real solution. >=20 >=20 >> item 54) section 8 >>=20 >> receiving requests that may cross the bounds each AS is constrained >> into. >> ---^ >> Probably better as "within". >>=20 >=20 >=20 > [LM] OK. >=20 >=20 >> item 55) section 8 >>=20 >> The detailed discussion of how the MS enforces security against the >> ASs is helpful, but it does not mention how the MS discerns which >> requests come from AS1 and which come from AS2. >>=20 >> Dale >=20 >=20 > [LM] Thanks again for your detailed review: this is exactly the kind = of > thorough feedback we were looking for, as so far we had to rely on our > own, a bit biased and probably not very objective review process :-) >=20 > Lorenzo >=20 >=20 >> _______________________________________________ >> MEDIACTRL mailing list >> MEDIACTRL@ietf.org >> https://www.ietf.org/mailman/listinfo/mediactrl >> Supplemental Web Site: >> http://www.standardstrack.com/ietf/mediactrl >=20 >=20 > --=20 > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl From eburger@standardstrack.com Fri Apr 12 23:59:29 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA721F8BE2 for ; Fri, 12 Apr 2013 23:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.738 X-Spam-Level: X-Spam-Status: No, score=-101.738 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cPIqcBDzT6Q for ; Fri, 12 Apr 2013 23:59:29 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.237]) by ietfa.amsl.com (Postfix) with ESMTP id E71F021F8BD0 for ; Fri, 12 Apr 2013 23:59:28 -0700 (PDT) Received: from 1-193.icannmeeting.org ([199.91.193.1]:51993 helo=[10.196.202.183]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UQuQh-00037e-Jb; Fri, 12 Apr 2013 23:59:26 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_FAB3F50B-5066-4ABC-908D-D664B236555B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <8BCECE3D-1D11-44DF-83CC-0B8D4462B6E4@standardstrack.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Sat, 13 Apr 2013 02:59:16 -0400 References: <20130411214409.51DDEB1E003@rfc-editor.org> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: "mediactrl@ietf.org list mailing" Subject: [MEDIACTRL] Fwd: RFC 6917 on Media Resource Brokering X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 06:59:30 -0000 --Apple-Mail=_FAB3F50B-5066-4ABC-908D-D664B236555B Content-Type: multipart/alternative; boundary="Apple-Mail=_826DD40A-846F-4FFD-9F72-255CC39FF01E" --Apple-Mail=_826DD40A-846F-4FFD-9F72-255CC39FF01E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Richard - Please make the following updates to our charter: Mixer Control Protocol to IESG Done Broker Protocol WGLC Done Broker Protocol to IESG Done Media Control Call Flows WGLC May 2013 Media Control Call Flows to IESG July 2013 Thanks! - Eric Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: [MEDIACTRL] RFC 6917 on Media Resource Brokering > Date: April 11, 2013 5:44:09 PM EDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: mediactrl@ietf.org, rfc-editor@rfc-editor.org >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6917 >=20 > Title: Media Resource Brokering=20 > Author: C. Boulton, L. Miniero, > G. Munson > Status: Standards Track > Stream: IETF > Date: April 2013 > Mailbox: chris@ns-technologies.com,=20 > lorenzo@meetecho.com,=20 > gamunson@gmail.com > Pages: 136 > Characters: 280399 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-mediactrl-mrb-19.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6917.txt >=20 > The MediaCtrl working group in the IETF has proposed an architecture > for controlling media services. The Session Initiation Protocol > (SIP) is used as the signaling protocol that provides many inherent > capabilities for message routing. In addition to such signaling > properties, a need exists for intelligent, application-level media > service selection based on non-static signaling properties. This is > especially true when considered in conjunction with deployment > architectures that include 1:M and M:N combinations of Application > Servers and Media Servers. This document introduces a Media Resource > Broker (MRB) entity, which manages the availability of Media Servers > and the media resource demands of Application Servers. The document > includes potential deployment options for an MRB and appropriate > interfaces to Application Servers and Media Servers. >=20 > This document is a product of the Media Server Control Working Group = of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl --Apple-Mail=_826DD40A-846F-4FFD-9F72-255CC39FF01E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = Done
Broker Protocol WGLC = Done
Broker Protocol to IESG = Done
Media Control Call Flows WGLC May = 2013
Media Control Call Flows to IESG July = 2013

Thanks!
- = Eric

Begin forwarded message:

Subject: [MEDIACTRL] RFC 6917 on Media Resource = Brokering
Date: April 11, 2013 5:44:09 PM EDT

A new Request for Comments is now available in = online RFC libraries.


=        RFC 6917

=        Title: =      Media Resource Brokering
=        Author: =     C. Boulton, L. Miniero,
=             &n= bsp;      G. Munson
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       April 2013
=        Mailbox:    chris@ns-technologies.com, =
=             &n= bsp;      lorenzo@meetecho.com,
=             &n= bsp;      gamunson@gmail.com
=        Pages: =      136
=        Characters: 280399
=        Updates/Obsoletes/SeeAlso: =   None

       I-D = Tag:    draft-ietf-mediactrl-mrb-19.txt

=        URL: =        http://www.rfc-editor.o= rg/rfc/rfc6917.txt

The MediaCtrl working group in the IETF = has proposed an architecture
for controlling media services. =  The Session Initiation Protocol
(SIP) is used as the signaling = protocol that provides many inherent
capabilities for message = routing.  In addition to such signaling
properties, a need = exists for intelligent, application-level media
service selection = based on non-static signaling properties.  This is
especially = true when considered in conjunction with deployment
architectures = that include 1:M and M:N combinations of Application
Servers and = Media Servers.  This document introduces a Media Resource
Broker = (MRB) entity, which manages the availability of Media Servers
and the = media resource demands of Application Servers.  The = document
includes potential deployment options for an MRB and = appropriate
interfaces to Application Servers and Media = Servers.

This document is a product of the Media Server Control = Working Group of the IETF.

This is now a Proposed = Standard.

STANDARDS TRACK: This document specifies an Internet = standards track
protocol for the Internet community,and requests = discussion and suggestions
for improvements.  Please refer to = the current edition of the Internet
Official Protocol Standards (STD = 1) for the standardization state and
status of this protocol. =  Distribution of this memo is unlimited.

This announcement = is sent to the IETF-Announce and rfc-dist lists.
To subscribe or = unsubscribe, see
 http://www.iet= f.org/mailman/listinfo/ietf-announce
 http://ma= ilman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching = the RFC series, see http://www.rfc-editor.or= g/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.= html.

Requests for special distribution should be addressed = to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =  Unless
specifically noted otherwise on the RFC itself, all RFCs = are for
unlimited distribution.


The RFC Editor = Team
Association Management Solutions, = LLC


_______________________________________________
MEDIACTR= L mailing list
MEDIACTRL@ietf.org
https://www.i= etf.org/mailman/listinfo/mediactrl
Supplemental Web = Site:
http://www.standardstrack.com/ietf/mediactrl

= --Apple-Mail=_826DD40A-846F-4FFD-9F72-255CC39FF01E-- --Apple-Mail=_FAB3F50B-5066-4ABC-908D-D664B236555B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJRaQJFAAoJEDY/T2tCIPW3D7IP/0tKlOSI6rBXP9CBJ83zgGPS 3Zau0sl7QJf/sl02JYAqpeETd2//ozwBiJf/VBUhYG7Y48B9k61mNM2n7D/RRrMb WToBrWmISPE/HGMFnY/VXDocV2ydhmokL5SL/gLvX9lWMvOqj3FfDdPHNTG7pgua GYhYXoF+0fFAzCoMlVeSEbvX0qxbcG8w0OFbXR2gX9gsFVqqI8x7ccQCV+xzfLDE 0/3n/LM6dvouqxyGm7DXsWwfxLwI9+jCabNWu/zmtkdX9temcJ8dpkfOOPqmtEek GxBqRdzChSTP/+aoC0HPGTJkTY3g4tQ2zFybq05LjFGUJtQgiEoDmHjcf5z+zMLL C8fEzacXCV6vk0zTNZWWT1CWPZFCBat3KKIbSiMCeVrCN0XvD6xTYYcnxzPEDAd9 l/mg5zixjqtmDTXHK7+deXOcHXmGWR5KpZxKcPgHVFR1wfqQmJ+q/nZ1tPFJSeZt 3FO0JpitNitmi0vbjNip5Ks2RvUkMWRw0IoUvakHqoNyp2CJb4S8vvZL1ToA6Abc AbtEIRYlSallHLkKhzwGICU8ppiFc4wXNrHmLvLB+Lp5oT+7NDOQdWIXYrsWyurr NGPmkq26HZ2VBB5Ba8nlZlAlaXrFgSqkn5Z+S/Y6LvaZzNRAuehGnwpgVxNFJfV2 q2RMQPp2lW9YE9NqsC3y =sAM+ -----END PGP SIGNATURE----- --Apple-Mail=_FAB3F50B-5066-4ABC-908D-D664B236555B-- From lorenzo@meetecho.com Sat Apr 13 00:51:52 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D421F8FDC for ; Sat, 13 Apr 2013 00:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_BACKHAIR_23=1, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A375uN5tiQXc for ; Sat, 13 Apr 2013 00:51:49 -0700 (PDT) Received: from smtpdg12.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4000121F8FE9 for ; Sat, 13 Apr 2013 00:51:47 -0700 (PDT) Received: from rainpc ([79.46.24.65]) by smtpcmd04.ad.aruba.it with bizsmtp id PKrk1l00H1QG29K01KrkTS; Sat, 13 Apr 2013 09:51:46 +0200 Date: Sat, 13 Apr 2013 09:51:42 +0200 From: Lorenzo Miniero To: Eric Burger Message-ID: <20130413095142.709b0a10@rainpc> In-Reply-To: <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "mediactrl@ietf.org list mailing" Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 07:51:52 -0000 Hello Eric, there were some points in that thread where I asked for some more feedback, as I wasn't sure about the most apt way to go on. Anyway, I've already integrated the other comments, so I'll just publish that new version ASAP and take it from there. L. On Sat, 13 Apr 2013 02:57:23 -0400 Eric Burger wrote: > Are we done yet? > > On Dec 26, 2012, at 7:11 AM, Lorenzo Miniero wrote: > > > Hello Dale, > > > > first of all, thanks for your detailed review! I'm answering to this > > mail first, leaving the extracted issue of the previous issue to later, > > since, as you pointed out, that's a more general issue. > > > > I've added my replies inline prefixed by a [LM]. > > > > > > On Wed, 19 Dec 2012 15:09:45 -0500 (EST) > > worley@ariadne.com (Dale R. Worley) wrote: > > > >> Review of draft-ietf-mediactrl-call-flows-10 > >> > >> The first thing that comes to mind is that this is a massive body of > >> work, and tremendously useful for the implementer! > >> > > > > > > [LM] Thanks! That's exactly what we wanted to achieve. > > > > > >> I've listed the items in the order they appear in the draft. Almost > >> all of them are editorial rather than technical. The technical > >> questions are: > >> > >> item 15 (is the listing of control packages in the SDP important or not) > >> item 17 (the negotiation of the timeout value is vague) > >> item 35 (mixing of playback of two recordings) > >> item 38 (semantics of setgain) > >> item 53 (how does AS send media INVITE to the correct MS) > >> item 55 (how does the MS know which AS sent each request) > >> > >> item 1) various > >> > >> The indentation of the header lines identifying various messages is > >> inconsistent. I can find the following lines in various places: > >> > >> 1. AS -> MS (SIP INVITE) > >> A1. AS -> MS (CFW CONTROL, createconference) > >> A1. AS1 -> MS (CFW CONTROL, audit IVR) > >> 1. AS -> MS (CFW SYNC) > >> > >> However, it may be easiest to have the RFC Editor fix that by giving > >> them an appropriate instruction, as they are likely to manually adjust > >> the indentation of the examples anyway. > >> > > > > > > [LM] You're right, the indentation often varies, and the logic behind > > this currently is according to whether or not the example fits the page. > > Instructions about this would be welcome! > > > > > >> item 2) various > >> > >> There are a lot of places where an arrow seems to go from a network > >> entity to itself, such as "create conf and its ID" below: > >> > >> AS MS > >> | | > >> | 1. CONTROL (create conference) | > >> |++++++++++++++++++++++++++++++++>>| > >> | |--+ create > >> | | | conf and > >> | 2. 200 OK (conferenceid=Y) |<-+ its ID > >> |<<++++++++++++++++++++++++++++++++| > >> > >> However, the event described on the label, "create conf and its ID", > >> is not the transmission of a message, and so it doesn't seem like it > >> should be represented by an arrow. A more accurate alternative would > >> be: > >> > >> AS MS > >> | | > >> | 1. CONTROL (create conference) | > >> |++++++++++++++++++++++++++++++++>>| > >> | | create > >> | | conf and > >> | 2. 200 OK (conferenceid=Y) | its ID > >> |<<++++++++++++++++++++++++++++++++| > >> > > > > > > [LM] Yes, in that case the arrow was not meant as a network connection, > > but as a further step in the sequence diagram, that is what that > > CONTROL message triggers in the MS application logic. The same applies > > to all the examples where this happens. If you think the arrowless > > diagram is clearer to the reader we might remove them: the problem with > > this is that, without arrows, some diagrams might be harder to read, > > i.e., in terms of who does what in diagrams with several components > > interacting with each other. As an alternative, we might clarify what > > those arrows are and what they are not. What do you think about this? > > > > > > > >> item 3) section 1 > >> > >> "self-sustained" should be "self-contained". > >> > > > > > > [LM] Ok. > > > > > >> item 4) section 2 > >> > >> Note that due to RFC formatting conventions, this document often > >> splits SIP/SDP and CFW across lines whose content would exceed 72 > >> characters. > >> > >> "whose content ..." is applied to the wrong referent, a "lines", but > >> those lines are the post-split lines, not the pre-split lines. > >> Perhaps: > >> > >> Note that due to RFC formatting conventions, SIP/SDP and CFW lines > >> whose content exceeds 72 characters are split across lines. This > >> line folding is marked by a backslash at the end of the first line. > >> This backslash, the preceding whitespace, the following CRLF, and > >> the whitespace beginning the next line would not appear in the > >> actual protocol contents. > >> > > > > > > [LM] Thanks, we'll change the sentence. > > > > > >> item 5) section 2 > >> > >> Due to the same 72 characters limitation, this document also > >> sometimes splits the content of XML elements across lines: please > >> beware that, when this happens, no whitespace is actually meant to > >> be neither at the beginning nor at the end of the element content. > >> > >> This seems to be incorrect, as in many places, an XML *element*, that > >> is, everything from the start tag to the end tag (see XML spec, rule > >> "element"), is quite long and is necessarily split across lines, but > >> is also valid. (However, that interpretation depends on entities > >> respecting the common convention that whitespace character content is > >> to be ignored if it appears immediately within an element that does > >> not admit immediate character content.) > >> > >> I believe you meant "start tag" instead of "element". But in that > >> case, line breaks between the attributes of a start tag are valid in > >> XML (see XML spec, rule "STag"). If this is correct, the above > >> sentence can be omitted. > >> > >> However, the message B1 in section 7.1 may be an exception. See the > >> appropriate item. > >> > > > > > > [LM] We actually added this line after a comment of yours on the MRB > > document examples, which exhibited a similar behaviour. Since we wanted > > to clarify that the examples didn't include pre and post whitespaces, > > we added the text to make this clearer. If that's unneeded we can > > remove the sentence again. > > > > > >> item 6) section 3 > >> > >> This document makes use of the same terminology as the one that can > >> be found in the referenced documents. > >> > >> This is awkward. Perhaps: > >> > >> This document makes use of the same terminology as the referenced > >> documents [RFC6230] [RFC6231] [RFC6505] [I-D.ietf-mediactrl-mrb]. > >> > > > > > > [LM] Ok. > > > > > >> item 7) section 4 > >> > >> This section starts with a paragraph over one page long. Could it be > >> broken into multiple paragraphs? > >> > > > > > > [LM] Did you mean section 4.1? Section 4 starts with just a few lines. > > > > > >> item 8) section 4 > >> > >> It seems overly complicated to explicitly describe "categories" to > >> contain only four things. Also, the text needs to mention that Figure > >> 3 contains *two* diagrams, otherwise the accounting seems to be > >> incorrect. Perhaps: > >> > >> Four diagrams are provided. Two of them (Figure 1 and Figure 2) > >> describe normal operation of the framework. Figure 3 contains two > >> diagrams describing asynchronous event notifications. Figure 1 > >> embraces the MS perspective, whereas Figure 2 is on on the AS side. > >> The upper part of Figure 3 shows how events are generated, on the > >> MS side, by issuing a CONTROL message addressed to the AS; events > >> are acknowledged by the AS through standard 200 responses. Hence, > >> the behavior of the AS, which mirrors that of the MS, is depicted > >> in the lower part of the figure. > >> > > > > > > [LM] Good point, we'll fix this. > > > > > >> item 9) section 4 figure 1 > >> > >> I think the state machine could be clarified: > >> > >> - Replace the event "API 200" in "API 200/200" with "API terminate", > >> which is how the API termination is described on other arcs. > >> > >> - Replace the event "API 202" in "API 202/202" with "API update", > >> which is how the API non-termination is described on other arcs. > >> > >> - Further, change "API update" to "timer" or something like that, to > >> indicate that the MS CFW state machine must generate a 202 *based on > >> the passage of time*, not based on the API providing some sort of > >> "update". If these time intervals are globally fixed for the CFW > >> protocol, their fixed values could be written in. > >> > > > > > > [LM] Ok, we'll make this clearer. > > > > > >> - The states "'202' sent" and "'update' sent" have the same outgoing > >> transitions, so they should probably be merged. > >> > > > > > > [LM] I'm not sure about this: 202 is only sent after the first CONTROL > > message to tell the AS it may take a while to process the request, after > > which you can either have further 202 messages should the processing > > take even more time, or one or more UPDATE messages related to that > > CONTROL request after that. They're two different messages in the > > protocol semantics. Nevertheless, it's also true that, according to > > RFC6230, a 202 is basically a pre-REPORT message... any feedback on > > this? > > > > > >> - Is there truly an "Error" message that is comparable to the "200" > >> and "202" messages? Or is sending "Error" a shorthand for a cluster > >> of numeric response codes? If the latter, it would help to make > >> that clearer here in the introductory material. > >> > > > > > > [LM] Yes, errors are numeric codes (Section 7. in RFC6230). We'll fix > > the text. > > > > > >> - What happens if the API detects an error after 202 has been sent? > >> There is no "API Error" arc from "'202' sent"/"'update' confirmed". > >> > > > > > > [LM] Good point. The idea is that, once the MS sends a 202, the request > > has been correctly processed, and so is supposed to be fine as far as > > the protocol is concerned. I guess there could be circumstances when an > > errors occurs after that, e.g., in retrieving an audio file to be played > > to a UAC: in that case, the AS would be informed of the termination of > > the dialog/request in a REPORT terminate, including details on the issue > > which are Control Package specific. Do you think explaining this in the > > text may help readers? > > > > > >> item 10) section 4 figure 2 > >> > >> Clarifications of the state machine: > >> > >> - There is no "Error" arc from the "202 received" and "'update'" > >> states. Are errors impossible here? > >> > >> - The states "202 received" and "'update'" have the same outward arcs > >> and so could be merged. > >> > >> - The two figures are inconsistent regarding whether response numbers > >> (200, 202) are within quotes '...'. > >> > >> - The two figures are inconsistent regarding whether report categories > >> (update, terminate) are within quotes '...'. > >> > >> - The two figures are inconsistent regarding whether the sending of a > >> request or response in an arc's label is indicated using "send" or > >> not. > >> > >> item 11) section 4 figure 3 > >> > >> There are similar inconsistencies between figure 3 and figures 1 and 2. > >> > >> item 12) section 5 > >> > >> The term "COMEDIA" is used, and a reference is given to RFC 4145. But > >> that RFC does not use the term "COMEDIA" at all. The framework I-D > >> also uses "COMEDIA" without explicitly defining it. It would be > >> helpful to insert here a definition of "COMEDIA", which seems to be > >> synonymous with "media of type application/cfw". > >> > > > > > > [LM] I thought COMEDIA actually came from RFC4145, standing for > > "connection-oriented media". Even the MSRP RFC refers to it that way. If > > that's incorrect or incomplete we'll fix this in the next version. > > > > > >> item 13) section 5.1 > >> > >> If the request is fine, the MS answers with its own offer, > >> > >> shouldn't this be: > >> > >> If the request is fine, the MS answers with its answer, > >> > > > > > > [LM] Ok. > > > > > >> item 14) section 5.1 > >> > >> The MS replies with the list of packages it supports, by > >> adding a dummy example package to the list provided by the AS. > >> > >> The "by" should be removed, as the replying is not done "by adding"; > >> instead, the MS replies and also adds. > >> > > > > > > [LM] OK. > > > > > >> item 15) section 5.1 > >> > >> It is worth noting that this exchange of information is not meant > >> as a strict or formal negotiation of packages: in case the AS > >> realizes that one or more packages it needs are not supported > >> according to the indications sent by the MS, it may, or may not, > >> choose not to open a control channel with the MS at all, if its > >> application logic leads to such a decision. The actual negotiation > >> of control packages is done subsequently through the use of the > >> framework SYNC transaction. > >> > >> This confuses me: Either the list of packages in the SDP offer/answer > >> is significant or it is not. If it is not, why is it provided? > >> > >> In particular, if the MS may support packages that it does not admit > >> to in the answer, then when the AS sees an answer that does not > >> contain the needed packages, it will have to continue with the control > >> channel connection in order to determine if the MS *actually* supports > >> the needed packages or not. Thus, the MS could omit all ctrl-package > >> attributes in its answers all the time. > >> > >> Also, it's not clear whether the AS is required to provide the list of > >> packages it will need. If it is required, then the SDP can be used to > >> choose the correct MS based on MS capabilities. If it is not > >> required, a different architectural mechanism is needed. > >> > > > > > > [LM] That section refers to a draft Chris submitted to the MMUSIC WG > > some time ago: > > > > http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07 > > > > so any clarification about the purpose and constraints of such a > > mechanism should be addressed in the specification. Chris, do you think > > this behaviour could be clarified in the draft, in order to have it > > reflected in the Call Flows as a consequence? > > > > > >> item 16) section 5.3 > >> > >> Whether "keep alive" is hyphenated is not consistent. > >> > > > > > > [LM] The right word is "keep-alive", we'll make this consistent. > > > > > >> item 17) section 5.3 > >> > >> In the previous section it has been described how a timeout value for > >> the keep alive mechanism is negotiated. Specifically, in the example > >> the AS and the MS agreed on a value of 100 seconds. > >> > >> In fact, that section does not describe how the value is negotiated > >> (since it is not clear what happens if the MS dislikes the value > >> proposed by the AS). However, this is correct: > >> > >> In example in the previous section, the AS and the MS agreed on a > >> value of 100 seconds. > >> > > > > > > [LM] According to RFC6230, the 200 to the SYNC MUST have the same > > keep-alive value proposed in the original SYNC. Who sends the SYNC can > > change according to the COMEDIA negotiation. Specifically, "The previous > > steps ensure that the entity initiating the Control Channel connection > > is always the one specifying the keep-alive timeout period.". So, to > > answer your question, I guess that if a MS dislikes the value, it can > > just pick the active role and send a new SYNC with a new keep-alive > > value. > > > > > >> > >> item 18) section 6 > >> > >> Besides, unless stated otherwise, the same UAC session is referenced > >> in all the above mentioned examples. > >> > >> Is "above mentioned" the correct modifier? The previous paragraph > >> refers to "the following scenarios". > >> > > > > > > [LM] You're right, it's a bit unclear, we'll fix this. > > > > > >> item 19) section 6 figure 10 > >> > >> It would be useful at this point to make it clear that the two INVITEs > >> are different SIP dialogs (as these scenarios are constructed). (Or, > >> if the AS may be inline and acting as a proxy, describe that there may > >> be two dialogs or only one.) Including, replace the second "INVITE > >> (X)" with "INVITE (Y)" to show that the URIs need not be the same. > >> > > > > > > [LM] OK. > > > > > >> Also, why not include the establishment of the Control Channel in the > >> figure, as that will not need to be duplicated in any further figure. > >> > > > > > > [LM] It's not there as the Control Channel may already have been > > negotiated and synced in advance. That is, the AS may be redirecting > > calls to a MS it has already been already "talking with" for a while. > > We explained this at the beginning of the section, "All the examples > > assume that a Control Channel has already been correctly established > > and SYNCed between the reference AS and MS", as that was already > > addressed in the previous section. > > > > > >> item 20) section 6 figure 11 > >> > >> Figure 11 appears to be only a caption. Or is it the SIP signaling? > >> Expositions of protocol messages are rarely considered to be figures. > >> > > > > > > [LM] You're right, we made use of figures to simplify the formatting > > of the messages, we'll remove te caption. > > > > > >> item 21) section 6 > >> > >> The phrase "These three identifiers" is confusing because the text has > >> just introduced four identifiers. > >> > > > > > > [LM] Oops, right. > > > > > >> I assume that if the SDP from AS to MS also contains label attributes, > >> the Mediactrl framework specifies how they will be used (or ignored), > >> so that the "addressing" of media streams is not made ambiguous. > >> > >> item 22) section 6.1.2 > >> > >> The 202+REPORT(s) mechanism is used whenever the MS wants to tell > >> the AS that the requested operation might take some more time than > >> expected. > >> > >> This is probably incorrect. What you mean is, "the requested > >> operation might take more than *** seconds". The fixed or variable > >> time limit should be specified here. > >> > > > > > > [LM] Actually, the time is Control Package dependent. Different packages > > may have different timeouts. Quoting the framework, "A Control Package > > MUST explicitly define the circumstances under which the server sends > > 200 and 202 messages." > > > > > >> In this example, the preparation ends before the > >> timeout, and so the transaction is concluded with a 'REPORT > >> terminate', which acts as the 200 message in the previous example. > >> > >> The last clause is rather confusing, as 'REPORT terminate' is a > >> request, not a response, and thus doesn't "act like" a 200 message. > >> Perhaps: "which reports the end of the transaction (as did the 200 > >> message in the previous example)". > >> > > > > > > [LM] OK. > > > > > >> item 23) section 6.2 figure 18 > >> > >> It might be useful to distinguish the four(?) SIP dialogs involved. > >> > > > > > > [LM] Do you mean as in different figures? or clearer text? > > > > > >> item 24) section 6.2.2 > >> > >> Three hours is 10,800 seconds, not 1,800 seconds. I think the easiest > >> fix is to replace "3 hours" with "30 minutes". > >> > > > > > > [LM] Oops, ugly typo, will fix this (and good thing my math teacher is > > not reading this :-) ) > > > > > >> RFC 6230 section 6.2 > >> > >> An entity acting as a Control Server, on receiving a request, MUST > >> generate a response [...]. The response MUST conform to the ABNF > >> Responses MUST NOT include the 'Status' or 'Timeout' message > >> headers, [...] > >> > >> RFC 6230 section 6.3.2.1 > >> > >> A Control Server issuing a 202 response MUST ensure the message > >> contains a 'Timeout' message header. > >> > >> item 25) section 6.2.3 > >> > >> This section is rather difficult to follow. I'm not sure why, but > >> partly it's because the text doesn't rigorously make clear what events > >> are "before", that is, when the two audio channels of the original > >> conference are being recorded, and "after", when the two recordings > >> are being played back. For instance, in the second paragraph, the last > >> sentence is "after", but the first two sentences are "before". > >> Instead, there should be a paragraph break there, and starting "Later, > >> when we desire to play the whole conversation to UAC, the AS may > >> take...". > >> > > > > > > [LM] You're right, we'll try to make this clearer. > > > > > >> It would help if the UAC which is listening to the playback was called > >> "UAC3" or something like that, as "UAC" is also a generic term, and > >> it's not immediately clear that it is unrelated to UAC1 and UAC2. > >> > >> It would also help if the two *recordings* had names different from > >> the UACs during the recording. In particular "play UAC1 on confY" is > >> hard for the naive reader to understand until he realizes that "UAC1" > >> means the recording file of the audio generated by UAC1. > >> > > > > > > [LM] Good points. > > > > > >> item 26) section 6.3 > >> > >> o The AS invokes the creation of a new conference instance by means > >> of a CONTROL request (1); this request is addressed to the > >> conferencing package (msc-mixer/1.0) and contains in the body the > >> directive (createconference) with all the desired settings for it; > >> > >> The antecedent of "it" is not particularly clear. The antecedent is > >> "a new conference", which is the 6th preceding noun phrase, which is > >> only determined because it is the first preceding noun phrase which > >> has settings. Better to say "... the desired settings for the new > >> conference instance". > >> > > > > > > [LM] Ok. > > > > > >> item 27) section 6.3.1 figure 30 > >> > >> This figure uses "UAC1" and "UAC2", but the other figures in 6.3 use > >> "UAC A", "UAC B", and "UAC C". Ditto for figure 31 and some of the > >> text. > >> > > > > > > [LM] Nice catch, we'll fix this. > > > > > >> item 28) section 6.3.4 figure 38 > >> > >> The notation "D+[a+c]" is clever, but "D+(A+C)/2" would be more > >> accurate. (And see the following item regarding the volume level.) > >> > > > > > > [LM] Ok. > > > > > >> item 29) section 6.3.4 > >> > >> The volume level at which the main conference is heard in the sidebar > >> is not stated consistently: > >> > >> the main conference. The mix of the conference, instead, must be > >> attached to the sidebar, but with a lower volume (50%), being just a > >> background to the actual conversation. This would allow both B and D > >> > >> 2. then, the main conference mix is attached to it as 'sendonly' and > >> with a -5dB gain to limit the volume of its own contribution to > >> 30% (so that B and D can hear each other louder, while still > >> listening to what's happening in the main conference in > >> background); > >> > >> | | | B1. CONTROL (join confX-->confY) | > >> | | |++++++++++++++++++++++++++++++++>>| > >> | | | |--+ join confX > >> | | | | | & confY > >> | | | B2. 200 OK |<-+ sendonly > >> | | |<<++++++++++++++++++++++++++++++++| (50% vol) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Of these, two references say 50% (-3dB) and two references say 30% or > >> -5dB. > >> > > > > > > [LM] You're right, we'll make this consistent. > > > > > >> item 30) section 6.3.5 figure 43 > >> > >> Is it intended that UAC (FCC) does not have any RTP going to the MS? > >> (Indeed, is it necessarily a UAC? But perhaps SIP is needed to set up > >> BFCP.) > >> > > > > > > [LM] Yes, to clarify the distinction between a simple participant and a > > chair we chose to only display RTP for the participant, with the chair > > moderating what happens on it. Whether or not the FCC has any RTP > > flowing is not relevant to the example and that's why we omitted it. > > That said, the chair does not need to be a UAC, you're right, and SIP is > > not mandated to set up BFCP (RFC4583 is only a way to do so, BFCP just > > talks of out of band mechanisms generally). We will remove the UAC for > > the FCC in the figure to make this clearer. > > > > > >> item 31) section 6.3.5 > >> > >> The participant UAC is labeled inconsistently as "UAC", "UAC (FCP)", > >> and "UAC1". ("UAC" may be correct, as the context for that term my be > >> describing a generic or abstract UAC.) Similarly, "UAC (FCC)" and > >> "UAC2" are used for the chair UAC. > >> > > > > > > [LM] We'll fix the diagrams accordingly. > > > > > >> item 32) section 6.3.5 > >> > >> It might be desirable to mention that the previous speaker should be > >> muted before UAC1 can be un-muted. Usually, this muting will happen > >> between the Accepted and Granted BFCP messages, so it probably should > >> be illustrated in the sequence of events. > >> > > > > > > [LM] That's actually not needed, as BFCP does not force an exclusive > > access to the resources it moderates. According to the policy in use, > > several participants may be granted the same resource (e.g., ability to > > talk) at the same time (e.g., in a conference bridge). > > > > > >> item 33) section 6.4 > >> > >> It might be helpful to expand "VCR" the first time it is used. > >> (Apparently it does not mean "video cassette recorder", and I see no > >> suitable meaning on the Wikipedia "disambiguation" page for "VCR".) > >> > > > > > > [LM] We borrowed this terminology from RFC6231, the IVR Control Package. > > The idea is to have "video cassette recorder"-lie controls, right, like > > the ability to play, pause, stop, rewind, etc. We'll expand this. > > > > > >> item 34) section 6.4.2 > >> > >> In fact, > >> rather than having the AS build different framework messages > >> according to the current time to build an announcement, > >> > >> This is difficult to read. Perhaps > >> > >> In fact, rather than having the AS build an announcement according > >> to the current time using different framework messages, > >> > > > > > > [LM] Ok. > > > > > >> item 35) section 6.4 > >> > >> The discussion of mixing in the background music should be contrasted > >> with the mixing of the two recordings during playback in section > >> 6.2.3. Naively, it would seem that the same mixing techniques could > >> be used in both cases, but the two sections implement mixing in > >> entirely different ways. > >> > > > > > > [LM] Are you talking of 6.4.2 (current time example)? If so, this was > > done on purpose, to exploit two different scenarios to showcase the use > > of two different techniques. You're right in saying that the same could > > be applied to both cases, nothing naive in this :-) > > > > > >> item 36) section 6.4.3 > >> > >> An example contains XML elements that seem to be unnecessarily > >> complex: > >> > >> > >> > >> * > >> > >> > >> > >> > >> As far as I can tell from the SRGS specification, functions > >> more-or-less as a type of parenthesis, and is needed only when (1) a > >> "weight" or "repeat" attribute needs to be applied to the group, (2) > >> delimiting one alternative of a element, or (3) constructing > >> the "null" regular expression (that consumes no input and always > >> matches). Thus, these examples can be simplified to: > >> > >> > >> * > >> > >> > >> > >> Then again, if the example is taken from a real interaction, perhaps > >> it is best to leave it as it really happened. > >> > > > > > > [LM] I'm not an expert of SRGS, so I'm not sure about this. This is how > > we implemented it in our Media Server, and it works this way, but it > > would be nice to hear from other implementers to see if they usually > > realize similar scenarios in a different way! > > > > > >> item 37) section 6.4.3 > >> > >> to implement is a , and we are only interested in two- > >> digits DTMF strings (maxdigits); the AS is not interested in a > >> > >> "two-digits" should be "two-digit". (Because this phrase is used as a > >> modifier of "DTMF strings", the "digit" is not plural.) > >> > > > > > > [LM] Ok. > > > > > >> instructs the MS into modifying the volume of the UAC-->conference > >> > >> "into modifying" would better be "to modify". > >> > > > > > > [LM] Ok. > > > > > >> audio flow (setgain=-5dB sendonly); notice how the request also > >> > >> This is probably intended to be "-3dB", as all other uses of setgain > >> in this section (including the displayed messages) use a 3 dB > >> increment. > >> > > > > > > [LM] Right, we0ll make this consistent. > > > > > >> item 38) section 6.4.3 > >> > >> This section leads to a question about the semantics of the >> controltype="setgain" ...> operation: Clearly, initially the stream > >> is output at the same volume as the input media. But when " >> controltype='setgain' value='+1'>" is applied, does that cause the > >> stream's output volume to be set to +1 dB *relative to the input > >> media* or to +1 dB *relative to the previous volume setting*? > >> > >> E.g., if I apply that operation twice, does the second application > >> leave the amplification at +1 dB or raise it to +2 dB? > >> > >> The examples in section 6.4.3 suggest the second interpretation. > >> > >> The text in draft-ietf-mediactrl-mixer-control-package-14 is not clear > >> on this point: "setgain" is only discussed in section 4.2.2.5.1, and > >> it says "use the value of the "value" attribute as a specific gain > >> measured in dB to apply". That would be most likely to mean "as a > >> specific gain measured in dB to apply to the input", which suggests > >> the first interpretation. > >> > >> In any case, the semantics of this need to be clarified and the > >> example adjusted accordingly. > >> > > > > > > [LM] If I recall correctly, when we first implemented this we discussed > > it with the IVR authors during a meeting. If I'm not wrong the > > conclusion was that setgain *sets* the gain, and does not modify the > > previous value. I don't have the MS code in front of me right now, > > though, I'll have to double check how we implemented this and let you > > know. > > > > IVR authors, any insight on this from a specification point of view? > > > > > >> item 39) section 7.1 > >> > >> Each MS makes use of the publishing interface to provide an MRB with > >> relevant information. > >> > >> In the relationship between the MRB and MS, the MRB initiates the > >> relationship. Thus, it would be clearer to express this: > >> > >> An MRB makes use of the MS's publishing interface to acquire > >> relevant information. > >> > >> It is > >> enough to point out that, in this case, the MRB adds a new voice to > >> the 'Packages' it needs support for (mrb-publish/1.0). > >> > >> "voice" should be "item". > >> > >> All > >> this messages flow through the control channel as all the messages in > >> ---^^^^ > >> should be "these" > >> ----------------------------------------------------^ > >> insert "do" > >> this document. > >> > > > > > > [LM] Ok. > > > > > >> item 40) section 7.1 message B1 > >> > >> This seems to be the only place in the draft where whitespace has been > >> introduced where character content is valid, and so there is a > >> question whether the draft needs to indicate that the whitespace would > >> not be present on the wire. The relevant elements are: > >> > >> > >> > >> > >> nbest > >> > >> > >> > >> > >> single-view > >> > >> > >> dual-view > >> > >> > >> dual-view-crop > >> > >> > >> dual-view-2x1 > >> > >> > >> dual-view-2x1-crop > >> > >> > >> quad-view > >> > >> > >> multiple-5x1 > >> > >> > >> multiple-3x3 > >> > >> > >> multiple-4x4 > >> > >> > >> > >> > >> I'm not sure if the schema defining urn:ietf:params:xml:ns:mrb-publish > >> indicates that the whitespace before and after the mixing mode names > >> is to be ignored. But this might be a place to use the > >> backslash-line-folding convention specified in section 2: > >> > >> > >> > >> \ > >> nbest \ > >> > >> > >> > >> \ > >> single-view \ > >> > >> \ > >> dual-view \ > >> > >> \ > >> dual-view-crop \ > >> > >> \ > >> dual-view-2x1 \ > >> > >> \ > >> dual-view-2x1-crop \ > >> > >> \ > >> quad-view \ > >> > >> \ > >> multiple-5x1 \ > >> > >> \ > >> multiple-3x3 \ > >> > >> \ > >> multiple-4x4 \ > >> > >> > >> > >> > > > > > > [LM] Yes, as I anticipated, we added that text to reflect a similar > > comment you made when reviewing the MRB draft. This fix you suggest > > makes sense, so we'll add it to the draft. > > > > > >> item 41) section 7.1, section 7.2, section 7.2.1 > >> > >> In the Inline mode, instead, the MRB is in the > >> path between the AS and the pool of MSs it is handling. > >> > >> Anyway, the MRB is also > >> conceived to work with ASs that are unaware of its functionality, > >> > >> and the SIP addresses of the chosen MSs. > >> > >> Generally, "AS" and "MS" are used as the plurals of "AS" and "MS", but > >> in these instances, "ASs" and "MSs" are used. > >> > > > > > > [LM] You're right, I fixed this in the MRB and not here, sorry. Besides, > > ASs sounds really bad... :-) > > > > > >> item 42) section 7.1 > >> > >> request itself and an SDP related to related to either the creation > >> -----------------------------^^^^^^^^^^^^^^^^^^^^^ > >> "related to" is duplicated. > >> > >> item 43) section 7.2.1 > >> > >> MS the MRB has deemed better capable to fulfill the AS requirements), > >> -------------------------^^^^^^ > >> This should be "best". > >> -------------------------------------------------------^^ > >> This should be "AS's" or "AS'" (depending on which spelling convention > >> we are using). > >> > >> targeting the request, and as a consequence picks up two MS which > >> --------------------------------------------------^^^^^^^^ > >> I think you want "picks" here. > >> > >> after the Query the AS<->interaction becomes 1:1, UAC media dialogs > >> ----------------------------^ > >> Something appears to be missing here. > >> > > > > > > [LM] We'll fix them all. > > > > > >> item 44) section 7.2.2.1, section 7.2.2.2, section 7.2.3 > >> > >> I think it would make the diagrams a little easier for the naive > >> reader to follow if the media types specified in the SDP of the > >> message bodies were given. E.g., if an INVITE or 200 carries an > >> application/sdp body for audio media, that is shown on the diagram. > >> This would be particularly helpful in 7.2.3, where it takes the reader > >> more consideration to deduce what the media types must be. Updated in > >> this way, the diagrams are as follows. (But this has removed the > >> comments noting where the SDP has been copied from one message to > >> another. That may need to be improved.) > > > > > > [LM] Ok, we'll try and improve this to make it clearer. > > > > > >> > >> 7.2.2.1. Inline-aware Mode: CFW-based approach > >> > >> AS MRB MS > >> | | | > >> | 1. INVITE | | > >> | (multipart/mixed: | | > >> | audio, | | > >> | application/mrb-consumer+xml) | > >> |---------------------->| | > >> | 2. 100 (Trying) | | > >> |<----------------------| | > >> | |--+ Extract SDP and | > >> | | | MRB payloads; handle | > >> | |<-+ Consumer request to | > >> | | pick MS | > >> | | | > >> | | 3. INVITE | > >> | | (audio) | > >> | |-------------------------->| > >> | | 4. 100 (Trying) | > >> | |<--------------------------| > >> | | |--+ Negotiate > >> | | | | CFW Control > >> | | |<-+ Channel > >> | | 5. 200 OK | > >> | | (audio) | > >> | |<--------------------------| > >> | | 6. ACK | > >> | |-------------------------->| > >> | Prepare new +--| | > >> | payload with | | | > >> | SDP from MS and +->| | > >> | Consumer reply | | > >> | | | > >> | 7. 200 OK | | > >> | (multipart/mixed: | | > >> | audio, | | > >> | application/mrb-consumer+xml) | > >> |<----------------------| | > >> | 8. ACK | | > >> |---------------------->| | > >> | | | > >> |--+ Read Cons. reply | | > >> | | and use SDP to | | > >> |<-+ create CFW Chn. | | > >> | | | > >> | | > >> |<<############## TCP CONNECTION #################>>| > >> | | > >> | CFW SYNC | > >> |++++++++++++++++++++++++++++++++++++++++++++++++++>| > >> | | > >> > >> 7.2.2.2. Inline-aware Mode: Media dialog-based approach > >> > >> UAC AS MRB MS > >> | | | | > >> | 1. INVITE | | | > >> | (audio) | | | > >> |-------------->| | | > >> | 2. 100 Trying | | | > >> |<--------------| | | > >> | | 3. INVITE | | > >> | | (multipart/mixed: | | > >> | | audio, | | > >> | | application/mrb-consumer_xml) | > >> | |---------------------->| | > >> | | 4. 100 (Trying) | | > >> | |<----------------------| | > >> | | |--+ Extract SDP and | > >> | | | | MRB payloads; handle | > >> | | |<-+ Consumer request to | > >> | | | pick Media Servers | > >> | | | | > >> | | | 5. INVITE | > >> | | | (audio) | > >> | | |------------------------->| > >> | | | 6. 100 (Trying) | > >> | | |<-------------------------| > >> | | | +--| > >> | | | Handle media dialog | | > >> | | | (connection-id) +->| > >> | | | | > >> | | | 7. 200 OK | > >> | | | (audio) | > >> | | |<-------------------------| > >> | | | 8. ACK | > >> | | |------------------------->| > >> | | Prepare new +--| | > >> | | payload with | | | > >> | | SDP from MS and +->| | > >> | | Consumer reply | | > >> | | | | > >> | | 9. 200 OK | | > >> | | (multipart/mixed: | | > >> | | audio, | | > >> | | application/mrb-consumer+xml) | > >> | |<----------------------| | > >> | | 10. ACK | | > >> | |---------------------->| | > >> | | | | > >> | |--+ Read Cons. reply | | > >> | | | and send SDP | | > >> | |<-+ back to UAC | | > >> | 11. 200 OK | | | > >> | (audio) | | | > >> |<--------------| | | > >> | 12. ACK | | | > >> |-------------->| | | > >> | | | | > >> |<<*************************** RTP ******************************>>| > >> | | | | > >> | |--+ Negotiate | | > >> | | | CFW channel | | > >> | |<-+ towards MS | | > >> | | (if needed) | | > >> | | | | > >> | |<<############## TCP CONNECTION ################>>| > >> | | | > >> | | CFW SYNC | > >> | |+++++++++++++++++++++++++++++++++++++++++++++++++>| > >> | | | > >> > >> 7.2.3. Inline-unaware Mode > >> > >> AS MRB MS > >> | | | > >> | 1. INVITE | | > >> | (application/cfw) | | > >> |---------------------->| | > >> | 2. 100 (Trying) | | > >> |<----------------------| | > >> | |--+ Pick a MS | > >> | | | and redirect | > >> | |<-+ INVITE there | > >> | | | > >> | | 3. INVITE | > >> | | (application/cfw) | > >> | |-------------------------->| > >> | | 4. 100 (Trying) | > >> | |<--------------------------| > >> | | |--+ Negotiate > >> | | | | CFW Control > >> | | |<-+ Channel > >> | | 5. 200 OK | > >> | | (application/cfw) | > >> | |<--------------------------| > >> | | 6. ACK | > >> | |-------------------------->| > >> | | | > >> | 7. 200 OK | | > >> | (application/cfw) | | > >> |<----------------------| | > >> | 8. ACK | | > >> |---------------------->| | > >> | | | > >> | | > >> |<<############## TCP CONNECTION #################>>| > >> | | > >> | CFW SYNC | > >> |++++++++++++++++++++++++++++++++++++++++++++++++++>| > >> | | > >> > >> item 45) section 7.2.2 > >> > >> An AS willing to issue a Concumer request by means of SIP, has to do > >> ----------------------------^ > >> This should be "Consumer". > >> > >> envisages two kind of SIP dialogs a Consumer request may be sent > >> -----------------^ > >> This should be "kinds". > >> > >> setup a control channel) or a UAC media dialog (a SIP dialog the AS > >> ---^ > >> This should be "set up". ("set up" functions like a verb; "setup" > >> functions like a noun.) > >> > >> The behaviour in the two cases, which are called respectively CFW- > >> -------^ > >> Probably better to say "behaviours" here. > >> based and Media dialog-based approach, is only slightly different, > >> ------------------------------------------^ > >> Use "are", to go with "behaviors". > >> > > > > > > [LM] OK. > > > > > >> item 46) section 7.2.2.1, section 7.2.2.2 > >> > >> Please note that, to ease the reading of the protocol contents, a > >> simple '=_Part' is used whenever a boundary for a 'multipart/mixed' > >> payload is provided, instead of the actual boundary that would be > >> inserted in the SIP messages. > >> > >> This seems like a poor strategy, as the resulting figures are not > >> strictly correct. Perhaps use "Part" as the boundary value, which > >> would result in figures that look like the following, which strictly > >> correct and are just as easy to read: > >> > >> [..] > >> Content-Type: multipart/mixed;boundary="Part" > >> > >> --Part > >> Content-Type: application/sdp > >> > >> v=0 > >> o=- 2890844526 2890842807 IN IP4 as.example.com > >> [...] > >> > >> --Part > >> Content-Type: application/mrb-consumer+xml > >> > >> > >> >> xmlns="urn:ietf:params:xml:ns:mrb-consumer"> > >> [...] > >> > >> > >> --Part-- > >> > > > > > > [LM] I think we did it this way after a comment received on the list: > > Chris and I did the same for the examples in the MRB draft, for instance. > > If you think it might improve the readibility of the document we'll > > change this. > > > > > >> In both of these sections, just before the message listings, there is > >> a line containing only: > >> > >> o > >> > > > > > > [LM] Probably a leftover, we'll remove it. > > > > > >> In the following message titles, "SDP" appears in lower case: > >> > >> section 7.2.2.1: > >> 3. MRB -> MS (INVITE sdp only) > >> 5. MRB <- MS (200 OK sdp) > >> section 7.2.2.2: > >> 5. MRB -> MS (INVITE sdp only) > >> 7. MRB <- MS (200 OK sdp) > >> 11. UAC <- AS (200 OK sdp) > >> > >> item 47) section 7.2.3 > >> > >> pick a MS rather than another. > >> --------^ > >> Probably should be "one", to contrast with "another". > >> > > > > > > [LM] OK. > > > > > >> item 48) section 7.2.3 > >> > >> This example does not give the content of the messages, unlike the > >> previous two examples. > >> > > > > > > [LM] It's because in the IUMM mode no Consumer transaction is involved. > > It's a normal RFC6230 Control Channel negotiation where the MRB acts > > as an intermediary, that is, picking a MS for the AS according to some > > logic. In this case, in fact, the AS does not support the MRB > > specification, and so just tries to set up a control channel the way > > it knows. > > > > > >> item 49) section 7.3.1 > >> > >> This section is titled "Query/IAMM". The call flow does mesh with the > >> call flow in section 7.2.1, "Query Mode", but it does not mesh with > >> the call flow in section 7.2.2.1, "Inline-aware Mode: CFW-based > >> approach" nor with the call flow in section 7.2.2.2, "Inline-aware > >> Mode: Media dialog-based approach". > >> > >> It would probably be best to change the title of the section to > >> "Query". If necessary, an additional section should be added giving > >> examples relevant to inline-aware mode. > >> > >> item 50) section 7.3.1, section 7.3.2 > >> > >> The use of "IAMM" and "IUMM" is a bit opaque here, as those acronyms > >> are not explicitly expanded anywhere in this document. They seem to > >> mean what is called "inline-aware mode" and "inline-unaware mode", but > >> the acronyms of those phrases aren't the same as the acronyms used. > >> > >> Perhaps these section titles could be changed to resemble those of > >> 7.2.*, "7.3.1. Query and Inline-aware Mode" and "7.3.2. Inline-unaware > >> Mode". That doesn't fix the problem with the acronyms per se but does > >> make the titles clearer. > >> > > > > > > [LM] You're right about both comments, we'll try to make this clearer > > and more consistent across the document. > > > > > >> item 51) section 7.3.1 > >> > >> We might want to mention that in this scenario, the AS obtains > >> assignment of an MS *before* any UAC makes a request, in order to have > >> facilities to satisfy future SIP requests. That is probably how AS's > >> operate in practice, but a naive reader might expect that the AS will > >> make the consumer request only after the AS receives a demand for its > >> services. > > > > > > [LM] Actually both Fig.53 and 54 show the AS creating a control channel > > before receiving an INVITE from the UAC. Or was your point about a > > different aspect? > > > > > >> > >> Nevertheless, there are cases when having an MRB in the signalling > >> path ... > >> > >> You might want to say "the SIP signalling path" here. By my count, > >> there are *three* different signalling paths: the COMEDIA negotiation > >> (INVITE with application/cfw SDP), the CFW connection, and the SIP > >> signalling (INVITE with audio/etc. SDP). > >> > > > > > > [LM] OK. > > > > > >> item 52) section 7.3.2 > >> > >> As mentioned previously, in such a case the AS would interact with > >> What case is "in such a case"? (This is the first sentence of a > >> section.) It seems that this paragraph is trying to contrast "such a > >> case" with "IUMM", but it's not clear what is going on. > >> > > > > > > [LM] It's referring to the case described by the section title, which is > > a poor editing choice. We'll make this more explicit. > > > > > >> That said, the IUMM case is also very interesting with respect to the > >> media dialogs management. In fact, in the MRB-unaware mode there > >> ---------^ > >> This should be "dialog". > > > > > > [LM] OK. > > > > > >> would be no Consumer request and an AS would actually see the MRB as > >> an MS. This means that, unlike the previous scenarios, there is > >> actually no choice, meaning the MRB would likely be in the signaling > >> ------------^ > >> What is there "no choice" of? The obvious choice is that of a MS, but > >> the MRB clearly can choose which MS to sent the request to. > > > > > > [LM] Probably a poorly translated sentence, as this makes more sense in > > Italian. The sentence is trying to say that there is no active selection > > process driven by an AS<->MRB interaction so yes, something eventually > > leading to choosing a specific MS according to that. That's why the > > document then explains a potential approach to take care of this. > > > > > >> path anyway. The MRB could either redirect the AS to a MS directly > >> or transparently act a proxy/B2BUA and contact a MS (according to > >> implementation-specific policies) on behalf of the unaware AS. > >> > >> To overcome the scalability limitations of such an approach, the MR > >> --------------------------------------------------------------^ > >> You should add here "at least in regard to the MRB being in the SIP > >> signalling path for all calls" -- as far as I can tell, this is the > >> only scaling problem this approach removes. (The major one is that > >> all calls handled by the AS have to be handled by only one MS.) > >> > > > > > > [LM] OK. > > > > > >> Rather than recurring to explicit redirection, or always > >> ---------------^ > >> This isn't the right word. Perhaps "resorting" was intended? > >> > > > > > > [LM] Yes, we'll fix this. > > > > > >> item 53) section 7.3.2 > >> > >> While apparently not a problem, this raises an issue when the same > >> unaware AS has several sessions with different MS: the AS would only > >> see one "virtual" MS (the MRB) and so it would relay all calls there, > >> making it hard for the MRB to understand where these media dialogs > >> should belong: specifically, whether the UAC calling belongs to the > >> AS application logic leading to MS1 or MS2, or wherever else. > >> > >> This seems to be a deficiency in the CFW protocol: If the AS > >> establishes a CFW channel with the MS (via a SIP URI to an MRB), and > >> then later the AS wants to addresses a SIP INVITE to the MS, it has no > >> choice but to use the same SIP URI (which routes to the MRB). This > >> makes it impossible for the MRB to associate the SIP INVITE with the > >> CFW connection, and thus it is difficult for the MRB to route the > >> INVITE to the same MS. > >> > >> What seems to be needed is for either the COMEDIA response > >> (application/cfw) or CFW connection to provide a SIP URI that is the > >> "real" SIP URI of the far-end of the CFW channel. > >> > >> Actually, this seems to be a problem even if an AS is addressing an MS > >> URI, but the URI resolves to a redundant set of MSs: There seems to > >> be no way to ensure that when a CFW channel is established that a > >> subsequent SIP INVITE can be sent to the same MS. This issue seems to > >> be discussed in RFC 6230 section 3, but I can't find any solution > >> there. > >> > > > > > > [LM] The way it works now is that, for a specific MS, the same SIP URI > > is used for both negotiating a control channel and attaching media > > dialogs, yes. A way to overcome this may having the MS redirect media > > dialogs to a different SIP URI when it receives them (that is, treat > > control and media dialogs differently) but I realize how this sounds > > like an implementation hack rather than a real solution. > > > > > >> item 54) section 8 > >> > >> receiving requests that may cross the bounds each AS is constrained > >> into. > >> ---^ > >> Probably better as "within". > >> > > > > > > [LM] OK. > > > > > >> item 55) section 8 > >> > >> The detailed discussion of how the MS enforces security against the > >> ASs is helpful, but it does not mention how the MS discerns which > >> requests come from AS1 and which come from AS2. > >> > >> Dale > > > > > > [LM] Thanks again for your detailed review: this is exactly the kind of > > thorough feedback we were looking for, as so far we had to rely on our > > own, a bit biased and probably not very objective review process :-) > > > > Lorenzo > > > > > >> _______________________________________________ > >> MEDIACTRL mailing list > >> MEDIACTRL@ietf.org > >> https://www.ietf.org/mailman/listinfo/mediactrl > >> Supplemental Web Site: > >> http://www.standardstrack.com/ietf/mediactrl > > > > > > -- > > Lorenzo Miniero, COB > > > > Meetecho s.r.l. > > Web Conferencing and Collaboration Tools > > http://www.meetecho.com > > _______________________________________________ > > MEDIACTRL mailing list > > MEDIACTRL@ietf.org > > https://www.ietf.org/mailman/listinfo/mediactrl > > Supplemental Web Site: > > http://www.standardstrack.com/ietf/mediactrl > -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From radhika.r.roy.civ@mail.mil Sat Apr 13 08:04:44 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6835F21F86C4 for ; Sat, 13 Apr 2013 08:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QUmEn1gwOYU for ; Sat, 13 Apr 2013 08:04:43 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id EC69421F86BC for ; Sat, 13 Apr 2013 08:04:42 -0700 (PDT) Received: from UCOLHP3H.easf.csd.disa.mil (131.64.100.149) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 13 Apr 2013 15:04:28 +0000 Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.116]) by UCOLHP3H.easf.csd.disa.mil ([131.64.100.149]) with mapi id 14.03.0123.003; Sat, 13 Apr 2013 15:04:28 +0000 From: "Roy, Radhika R CIV USARMY (US)" To: Eric Burger , "mediactrl@ietf.org" Thread-Topic: [MEDIACTRL] RFC 6917 on Media Resource Brokering (UNCLASSIFIED) Thread-Index: AQHONv3VOhrI5cwhXU6aqeTRII/u+5jTBKoAgAE6E6A= Date: Sat, 13 Apr 2013 15:04:27 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49A78218@ucolhp9b.easf.csd.disa.mil> References: <20130411214409.51DDEB1E003@rfc-editor.org> <0A241228-2798-42D3-B03C-BF896BBC267F@standardstrack.com> In-Reply-To: <0A241228-2798-42D3-B03C-BF896BBC267F@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0006_01CE3836.A8003B60" MIME-Version: 1.0 Subject: Re: [MEDIACTRL] RFC 6917 on Media Resource Brokering (UNCLASSIFIED) X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 15:04:44 -0000 ------=_NextPart_000_0006_01CE3836.A8003B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Classification: UNCLASSIFIED Caveats: NONE It is a great work and congratulations to all especially to the authors of RFC 6917. I know Eric also worked a lot in this area and authored some RFCs that has been the pre-cursor of this in the beginning of the SIP standards when no technical standards were available for decomposing of media servers and the call control application servers for invoking/creation of SIP services It is a great milestone for the industry as well because there has been so much struggles for creating a market based on OPEN standards of the media server that is so important for scalability of the large-scale SIP network which is being dominated by "proprietary" schemes especially blocking the competition for entering of more medium or smaller size vendors reducing the costs. History will record this in a way MEGACO/H.248 has done for the smooth migration of the monster TDM switches into more distributed scalable architecture to the IP-based packet switches. Best regards, Radhika Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_0006_01CE3836.A8003B60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMzA0MTMxNTA0MjNaMCMGCSqGSIb3DQEJBDEWBBTcURgky6YZgIGf72l3YMu6 HW+XOjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAHU+AOcgssPsNulpNWo3T72OU9sQc/dN9XeyWEJbpAsxJdRBiAz3E8fT+MEI9uXe7mAN yxOQezSp7XSvficzOPnCgyGcDfESZcfHhSdHuPbFjplOytQCKrD0BFDrxUQoCuAV0l3eulzdq7o2 G96saUW48qOiv59pYU62nK8RRrB68ltVPVRBK1PPTL7xCNWGbYe9ZSKclSnkq+KdvfGQ9beIfrng N4kDMKLsPD9WbQaHdwI3tMBLgyWeaKh5SNawPogjzp8Juydu1Tw13kj7conf0Dq6CCEDk/opOlag D2YZGZcmB2U2NRd82O27lrRuwrwhPygJ9Q+FsOSN2t23r8EAAAAAAAA= ------=_NextPart_000_0006_01CE3836.A8003B60-- From internet-drafts@ietf.org Sat Apr 13 10:24:52 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16AA21F8D28; Sat, 13 Apr 2013 10:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aejsJFxt5eAG; Sat, 13 Apr 2013 10:24:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 260B221F8C10; Sat, 13 Apr 2013 10:24:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130413172452.9227.6571.idtracker@ietfa.amsl.com> Date: Sat, 13 Apr 2013 10:24:52 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-call-flows-11.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 17:24:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Control Channel Framework (CFW) Call Flow Examples Author(s) : Alessandro Amirante Tobia Castaldi Lorenzo Miniero Simon Pietro Romano Filename : draft-ietf-mediactrl-call-flows-11.txt Pages : 171 Date : 2013-04-13 Abstract: This document provides a list of typical Media Control Channel Framework [RFC6230] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL- based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-call-flows-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-call-flows-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@meetecho.com Sat Apr 13 10:28:57 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CC121F8ADC for ; Sat, 13 Apr 2013 10:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.74 X-Spam-Level: ** X-Spam-Status: No, score=2.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_BACKHAIR_23=1, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TibfH-zy6ED4 for ; Sat, 13 Apr 2013 10:28:53 -0700 (PDT) Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6967021F89D8 for ; Sat, 13 Apr 2013 10:28:52 -0700 (PDT) Received: from rainpc ([79.56.18.127]) by smtpcmd03.ad.aruba.it with bizsmtp id PVUp1l00K2kVuav01VUpqU; Sat, 13 Apr 2013 19:28:50 +0200 Date: Sat, 13 Apr 2013 19:28:48 +0200 From: Lorenzo Miniero To: Eric Burger Message-ID: <20130413192848.08ca5248@rainpc> In-Reply-To: <20130413095142.709b0a10@rainpc> References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> <20130413095142.709b0a10@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "mediactrl@ietf.org list mailing" Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 17:28:57 -0000 Eric, I just published a new version of the draft. I take the opportunity to thank Dale again for his tremendous work on reviewing the document! What should be the way forward for the document now? Thanks, Lorenzo On Sat, 13 Apr 2013 09:51:42 +0200 Lorenzo Miniero wrote: > Hello Eric, > > there were some points in that thread where I asked for some more feedback, as I wasn't sure about the most apt way to go on. Anyway, I've already integrated the other comments, so I'll just publish that new version ASAP and take it from there. > > L. > > > On Sat, 13 Apr 2013 02:57:23 -0400 > Eric Burger wrote: > > > Are we done yet? > > > > On Dec 26, 2012, at 7:11 AM, Lorenzo Miniero wrote: > > > > > Hello Dale, > > > > > > first of all, thanks for your detailed review! I'm answering to this > > > mail first, leaving the extracted issue of the previous issue to later, > > > since, as you pointed out, that's a more general issue. > > > > > > I've added my replies inline prefixed by a [LM]. > > > > > > > > > On Wed, 19 Dec 2012 15:09:45 -0500 (EST) > > > worley@ariadne.com (Dale R. Worley) wrote: > > > > > >> Review of draft-ietf-mediactrl-call-flows-10 > > >> > > >> The first thing that comes to mind is that this is a massive body of > > >> work, and tremendously useful for the implementer! > > >> > > > > > > > > > [LM] Thanks! That's exactly what we wanted to achieve. > > > > > > > > >> I've listed the items in the order they appear in the draft. Almost > > >> all of them are editorial rather than technical. The technical > > >> questions are: > > >> > > >> item 15 (is the listing of control packages in the SDP important or not) > > >> item 17 (the negotiation of the timeout value is vague) > > >> item 35 (mixing of playback of two recordings) > > >> item 38 (semantics of setgain) > > >> item 53 (how does AS send media INVITE to the correct MS) > > >> item 55 (how does the MS know which AS sent each request) > > >> > > >> item 1) various > > >> > > >> The indentation of the header lines identifying various messages is > > >> inconsistent. I can find the following lines in various places: > > >> > > >> 1. AS -> MS (SIP INVITE) > > >> A1. AS -> MS (CFW CONTROL, createconference) > > >> A1. AS1 -> MS (CFW CONTROL, audit IVR) > > >> 1. AS -> MS (CFW SYNC) > > >> > > >> However, it may be easiest to have the RFC Editor fix that by giving > > >> them an appropriate instruction, as they are likely to manually adjust > > >> the indentation of the examples anyway. > > >> > > > > > > > > > [LM] You're right, the indentation often varies, and the logic behind > > > this currently is according to whether or not the example fits the page. > > > Instructions about this would be welcome! > > > > > > > > >> item 2) various > > >> > > >> There are a lot of places where an arrow seems to go from a network > > >> entity to itself, such as "create conf and its ID" below: > > >> > > >> AS MS > > >> | | > > >> | 1. CONTROL (create conference) | > > >> |++++++++++++++++++++++++++++++++>>| > > >> | |--+ create > > >> | | | conf and > > >> | 2. 200 OK (conferenceid=Y) |<-+ its ID > > >> |<<++++++++++++++++++++++++++++++++| > > >> > > >> However, the event described on the label, "create conf and its ID", > > >> is not the transmission of a message, and so it doesn't seem like it > > >> should be represented by an arrow. A more accurate alternative would > > >> be: > > >> > > >> AS MS > > >> | | > > >> | 1. CONTROL (create conference) | > > >> |++++++++++++++++++++++++++++++++>>| > > >> | | create > > >> | | conf and > > >> | 2. 200 OK (conferenceid=Y) | its ID > > >> |<<++++++++++++++++++++++++++++++++| > > >> > > > > > > > > > [LM] Yes, in that case the arrow was not meant as a network connection, > > > but as a further step in the sequence diagram, that is what that > > > CONTROL message triggers in the MS application logic. The same applies > > > to all the examples where this happens. If you think the arrowless > > > diagram is clearer to the reader we might remove them: the problem with > > > this is that, without arrows, some diagrams might be harder to read, > > > i.e., in terms of who does what in diagrams with several components > > > interacting with each other. As an alternative, we might clarify what > > > those arrows are and what they are not. What do you think about this? > > > > > > > > > > > >> item 3) section 1 > > >> > > >> "self-sustained" should be "self-contained". > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> item 4) section 2 > > >> > > >> Note that due to RFC formatting conventions, this document often > > >> splits SIP/SDP and CFW across lines whose content would exceed 72 > > >> characters. > > >> > > >> "whose content ..." is applied to the wrong referent, a "lines", but > > >> those lines are the post-split lines, not the pre-split lines. > > >> Perhaps: > > >> > > >> Note that due to RFC formatting conventions, SIP/SDP and CFW lines > > >> whose content exceeds 72 characters are split across lines. This > > >> line folding is marked by a backslash at the end of the first line. > > >> This backslash, the preceding whitespace, the following CRLF, and > > >> the whitespace beginning the next line would not appear in the > > >> actual protocol contents. > > >> > > > > > > > > > [LM] Thanks, we'll change the sentence. > > > > > > > > >> item 5) section 2 > > >> > > >> Due to the same 72 characters limitation, this document also > > >> sometimes splits the content of XML elements across lines: please > > >> beware that, when this happens, no whitespace is actually meant to > > >> be neither at the beginning nor at the end of the element content. > > >> > > >> This seems to be incorrect, as in many places, an XML *element*, that > > >> is, everything from the start tag to the end tag (see XML spec, rule > > >> "element"), is quite long and is necessarily split across lines, but > > >> is also valid. (However, that interpretation depends on entities > > >> respecting the common convention that whitespace character content is > > >> to be ignored if it appears immediately within an element that does > > >> not admit immediate character content.) > > >> > > >> I believe you meant "start tag" instead of "element". But in that > > >> case, line breaks between the attributes of a start tag are valid in > > >> XML (see XML spec, rule "STag"). If this is correct, the above > > >> sentence can be omitted. > > >> > > >> However, the message B1 in section 7.1 may be an exception. See the > > >> appropriate item. > > >> > > > > > > > > > [LM] We actually added this line after a comment of yours on the MRB > > > document examples, which exhibited a similar behaviour. Since we wanted > > > to clarify that the examples didn't include pre and post whitespaces, > > > we added the text to make this clearer. If that's unneeded we can > > > remove the sentence again. > > > > > > > > >> item 6) section 3 > > >> > > >> This document makes use of the same terminology as the one that can > > >> be found in the referenced documents. > > >> > > >> This is awkward. Perhaps: > > >> > > >> This document makes use of the same terminology as the referenced > > >> documents [RFC6230] [RFC6231] [RFC6505] [I-D.ietf-mediactrl-mrb]. > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> item 7) section 4 > > >> > > >> This section starts with a paragraph over one page long. Could it be > > >> broken into multiple paragraphs? > > >> > > > > > > > > > [LM] Did you mean section 4.1? Section 4 starts with just a few lines. > > > > > > > > >> item 8) section 4 > > >> > > >> It seems overly complicated to explicitly describe "categories" to > > >> contain only four things. Also, the text needs to mention that Figure > > >> 3 contains *two* diagrams, otherwise the accounting seems to be > > >> incorrect. Perhaps: > > >> > > >> Four diagrams are provided. Two of them (Figure 1 and Figure 2) > > >> describe normal operation of the framework. Figure 3 contains two > > >> diagrams describing asynchronous event notifications. Figure 1 > > >> embraces the MS perspective, whereas Figure 2 is on on the AS side. > > >> The upper part of Figure 3 shows how events are generated, on the > > >> MS side, by issuing a CONTROL message addressed to the AS; events > > >> are acknowledged by the AS through standard 200 responses. Hence, > > >> the behavior of the AS, which mirrors that of the MS, is depicted > > >> in the lower part of the figure. > > >> > > > > > > > > > [LM] Good point, we'll fix this. > > > > > > > > >> item 9) section 4 figure 1 > > >> > > >> I think the state machine could be clarified: > > >> > > >> - Replace the event "API 200" in "API 200/200" with "API terminate", > > >> which is how the API termination is described on other arcs. > > >> > > >> - Replace the event "API 202" in "API 202/202" with "API update", > > >> which is how the API non-termination is described on other arcs. > > >> > > >> - Further, change "API update" to "timer" or something like that, to > > >> indicate that the MS CFW state machine must generate a 202 *based on > > >> the passage of time*, not based on the API providing some sort of > > >> "update". If these time intervals are globally fixed for the CFW > > >> protocol, their fixed values could be written in. > > >> > > > > > > > > > [LM] Ok, we'll make this clearer. > > > > > > > > >> - The states "'202' sent" and "'update' sent" have the same outgoing > > >> transitions, so they should probably be merged. > > >> > > > > > > > > > [LM] I'm not sure about this: 202 is only sent after the first CONTROL > > > message to tell the AS it may take a while to process the request, after > > > which you can either have further 202 messages should the processing > > > take even more time, or one or more UPDATE messages related to that > > > CONTROL request after that. They're two different messages in the > > > protocol semantics. Nevertheless, it's also true that, according to > > > RFC6230, a 202 is basically a pre-REPORT message... any feedback on > > > this? > > > > > > > > >> - Is there truly an "Error" message that is comparable to the "200" > > >> and "202" messages? Or is sending "Error" a shorthand for a cluster > > >> of numeric response codes? If the latter, it would help to make > > >> that clearer here in the introductory material. > > >> > > > > > > > > > [LM] Yes, errors are numeric codes (Section 7. in RFC6230). We'll fix > > > the text. > > > > > > > > >> - What happens if the API detects an error after 202 has been sent? > > >> There is no "API Error" arc from "'202' sent"/"'update' confirmed". > > >> > > > > > > > > > [LM] Good point. The idea is that, once the MS sends a 202, the request > > > has been correctly processed, and so is supposed to be fine as far as > > > the protocol is concerned. I guess there could be circumstances when an > > > errors occurs after that, e.g., in retrieving an audio file to be played > > > to a UAC: in that case, the AS would be informed of the termination of > > > the dialog/request in a REPORT terminate, including details on the issue > > > which are Control Package specific. Do you think explaining this in the > > > text may help readers? > > > > > > > > >> item 10) section 4 figure 2 > > >> > > >> Clarifications of the state machine: > > >> > > >> - There is no "Error" arc from the "202 received" and "'update'" > > >> states. Are errors impossible here? > > >> > > >> - The states "202 received" and "'update'" have the same outward arcs > > >> and so could be merged. > > >> > > >> - The two figures are inconsistent regarding whether response numbers > > >> (200, 202) are within quotes '...'. > > >> > > >> - The two figures are inconsistent regarding whether report categories > > >> (update, terminate) are within quotes '...'. > > >> > > >> - The two figures are inconsistent regarding whether the sending of a > > >> request or response in an arc's label is indicated using "send" or > > >> not. > > >> > > >> item 11) section 4 figure 3 > > >> > > >> There are similar inconsistencies between figure 3 and figures 1 and 2. > > >> > > >> item 12) section 5 > > >> > > >> The term "COMEDIA" is used, and a reference is given to RFC 4145. But > > >> that RFC does not use the term "COMEDIA" at all. The framework I-D > > >> also uses "COMEDIA" without explicitly defining it. It would be > > >> helpful to insert here a definition of "COMEDIA", which seems to be > > >> synonymous with "media of type application/cfw". > > >> > > > > > > > > > [LM] I thought COMEDIA actually came from RFC4145, standing for > > > "connection-oriented media". Even the MSRP RFC refers to it that way. If > > > that's incorrect or incomplete we'll fix this in the next version. > > > > > > > > >> item 13) section 5.1 > > >> > > >> If the request is fine, the MS answers with its own offer, > > >> > > >> shouldn't this be: > > >> > > >> If the request is fine, the MS answers with its answer, > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> item 14) section 5.1 > > >> > > >> The MS replies with the list of packages it supports, by > > >> adding a dummy example package to the list provided by the AS. > > >> > > >> The "by" should be removed, as the replying is not done "by adding"; > > >> instead, the MS replies and also adds. > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> item 15) section 5.1 > > >> > > >> It is worth noting that this exchange of information is not meant > > >> as a strict or formal negotiation of packages: in case the AS > > >> realizes that one or more packages it needs are not supported > > >> according to the indications sent by the MS, it may, or may not, > > >> choose not to open a control channel with the MS at all, if its > > >> application logic leads to such a decision. The actual negotiation > > >> of control packages is done subsequently through the use of the > > >> framework SYNC transaction. > > >> > > >> This confuses me: Either the list of packages in the SDP offer/answer > > >> is significant or it is not. If it is not, why is it provided? > > >> > > >> In particular, if the MS may support packages that it does not admit > > >> to in the answer, then when the AS sees an answer that does not > > >> contain the needed packages, it will have to continue with the control > > >> channel connection in order to determine if the MS *actually* supports > > >> the needed packages or not. Thus, the MS could omit all ctrl-package > > >> attributes in its answers all the time. > > >> > > >> Also, it's not clear whether the AS is required to provide the list of > > >> packages it will need. If it is required, then the SDP can be used to > > >> choose the correct MS based on MS capabilities. If it is not > > >> required, a different architectural mechanism is needed. > > >> > > > > > > > > > [LM] That section refers to a draft Chris submitted to the MMUSIC WG > > > some time ago: > > > > > > http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07 > > > > > > so any clarification about the purpose and constraints of such a > > > mechanism should be addressed in the specification. Chris, do you think > > > this behaviour could be clarified in the draft, in order to have it > > > reflected in the Call Flows as a consequence? > > > > > > > > >> item 16) section 5.3 > > >> > > >> Whether "keep alive" is hyphenated is not consistent. > > >> > > > > > > > > > [LM] The right word is "keep-alive", we'll make this consistent. > > > > > > > > >> item 17) section 5.3 > > >> > > >> In the previous section it has been described how a timeout value for > > >> the keep alive mechanism is negotiated. Specifically, in the example > > >> the AS and the MS agreed on a value of 100 seconds. > > >> > > >> In fact, that section does not describe how the value is negotiated > > >> (since it is not clear what happens if the MS dislikes the value > > >> proposed by the AS). However, this is correct: > > >> > > >> In example in the previous section, the AS and the MS agreed on a > > >> value of 100 seconds. > > >> > > > > > > > > > [LM] According to RFC6230, the 200 to the SYNC MUST have the same > > > keep-alive value proposed in the original SYNC. Who sends the SYNC can > > > change according to the COMEDIA negotiation. Specifically, "The previous > > > steps ensure that the entity initiating the Control Channel connection > > > is always the one specifying the keep-alive timeout period.". So, to > > > answer your question, I guess that if a MS dislikes the value, it can > > > just pick the active role and send a new SYNC with a new keep-alive > > > value. > > > > > > > > >> > > >> item 18) section 6 > > >> > > >> Besides, unless stated otherwise, the same UAC session is referenced > > >> in all the above mentioned examples. > > >> > > >> Is "above mentioned" the correct modifier? The previous paragraph > > >> refers to "the following scenarios". > > >> > > > > > > > > > [LM] You're right, it's a bit unclear, we'll fix this. > > > > > > > > >> item 19) section 6 figure 10 > > >> > > >> It would be useful at this point to make it clear that the two INVITEs > > >> are different SIP dialogs (as these scenarios are constructed). (Or, > > >> if the AS may be inline and acting as a proxy, describe that there may > > >> be two dialogs or only one.) Including, replace the second "INVITE > > >> (X)" with "INVITE (Y)" to show that the URIs need not be the same. > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> Also, why not include the establishment of the Control Channel in the > > >> figure, as that will not need to be duplicated in any further figure. > > >> > > > > > > > > > [LM] It's not there as the Control Channel may already have been > > > negotiated and synced in advance. That is, the AS may be redirecting > > > calls to a MS it has already been already "talking with" for a while. > > > We explained this at the beginning of the section, "All the examples > > > assume that a Control Channel has already been correctly established > > > and SYNCed between the reference AS and MS", as that was already > > > addressed in the previous section. > > > > > > > > >> item 20) section 6 figure 11 > > >> > > >> Figure 11 appears to be only a caption. Or is it the SIP signaling? > > >> Expositions of protocol messages are rarely considered to be figures. > > >> > > > > > > > > > [LM] You're right, we made use of figures to simplify the formatting > > > of the messages, we'll remove te caption. > > > > > > > > >> item 21) section 6 > > >> > > >> The phrase "These three identifiers" is confusing because the text has > > >> just introduced four identifiers. > > >> > > > > > > > > > [LM] Oops, right. > > > > > > > > >> I assume that if the SDP from AS to MS also contains label attributes, > > >> the Mediactrl framework specifies how they will be used (or ignored), > > >> so that the "addressing" of media streams is not made ambiguous. > > >> > > >> item 22) section 6.1.2 > > >> > > >> The 202+REPORT(s) mechanism is used whenever the MS wants to tell > > >> the AS that the requested operation might take some more time than > > >> expected. > > >> > > >> This is probably incorrect. What you mean is, "the requested > > >> operation might take more than *** seconds". The fixed or variable > > >> time limit should be specified here. > > >> > > > > > > > > > [LM] Actually, the time is Control Package dependent. Different packages > > > may have different timeouts. Quoting the framework, "A Control Package > > > MUST explicitly define the circumstances under which the server sends > > > 200 and 202 messages." > > > > > > > > >> In this example, the preparation ends before the > > >> timeout, and so the transaction is concluded with a 'REPORT > > >> terminate', which acts as the 200 message in the previous example. > > >> > > >> The last clause is rather confusing, as 'REPORT terminate' is a > > >> request, not a response, and thus doesn't "act like" a 200 message. > > >> Perhaps: "which reports the end of the transaction (as did the 200 > > >> message in the previous example)". > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> item 23) section 6.2 figure 18 > > >> > > >> It might be useful to distinguish the four(?) SIP dialogs involved. > > >> > > > > > > > > > [LM] Do you mean as in different figures? or clearer text? > > > > > > > > >> item 24) section 6.2.2 > > >> > > >> Three hours is 10,800 seconds, not 1,800 seconds. I think the easiest > > >> fix is to replace "3 hours" with "30 minutes". > > >> > > > > > > > > > [LM] Oops, ugly typo, will fix this (and good thing my math teacher is > > > not reading this :-) ) > > > > > > > > >> RFC 6230 section 6.2 > > >> > > >> An entity acting as a Control Server, on receiving a request, MUST > > >> generate a response [...]. The response MUST conform to the ABNF > > >> Responses MUST NOT include the 'Status' or 'Timeout' message > > >> headers, [...] > > >> > > >> RFC 6230 section 6.3.2.1 > > >> > > >> A Control Server issuing a 202 response MUST ensure the message > > >> contains a 'Timeout' message header. > > >> > > >> item 25) section 6.2.3 > > >> > > >> This section is rather difficult to follow. I'm not sure why, but > > >> partly it's because the text doesn't rigorously make clear what events > > >> are "before", that is, when the two audio channels of the original > > >> conference are being recorded, and "after", when the two recordings > > >> are being played back. For instance, in the second paragraph, the last > > >> sentence is "after", but the first two sentences are "before". > > >> Instead, there should be a paragraph break there, and starting "Later, > > >> when we desire to play the whole conversation to UAC, the AS may > > >> take...". > > >> > > > > > > > > > [LM] You're right, we'll try to make this clearer. > > > > > > > > >> It would help if the UAC which is listening to the playback was called > > >> "UAC3" or something like that, as "UAC" is also a generic term, and > > >> it's not immediately clear that it is unrelated to UAC1 and UAC2. > > >> > > >> It would also help if the two *recordings* had names different from > > >> the UACs during the recording. In particular "play UAC1 on confY" is > > >> hard for the naive reader to understand until he realizes that "UAC1" > > >> means the recording file of the audio generated by UAC1. > > >> > > > > > > > > > [LM] Good points. > > > > > > > > >> item 26) section 6.3 > > >> > > >> o The AS invokes the creation of a new conference instance by means > > >> of a CONTROL request (1); this request is addressed to the > > >> conferencing package (msc-mixer/1.0) and contains in the body the > > >> directive (createconference) with all the desired settings for it; > > >> > > >> The antecedent of "it" is not particularly clear. The antecedent is > > >> "a new conference", which is the 6th preceding noun phrase, which is > > >> only determined because it is the first preceding noun phrase which > > >> has settings. Better to say "... the desired settings for the new > > >> conference instance". > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> item 27) section 6.3.1 figure 30 > > >> > > >> This figure uses "UAC1" and "UAC2", but the other figures in 6.3 use > > >> "UAC A", "UAC B", and "UAC C". Ditto for figure 31 and some of the > > >> text. > > >> > > > > > > > > > [LM] Nice catch, we'll fix this. > > > > > > > > >> item 28) section 6.3.4 figure 38 > > >> > > >> The notation "D+[a+c]" is clever, but "D+(A+C)/2" would be more > > >> accurate. (And see the following item regarding the volume level.) > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> item 29) section 6.3.4 > > >> > > >> The volume level at which the main conference is heard in the sidebar > > >> is not stated consistently: > > >> > > >> the main conference. The mix of the conference, instead, must be > > >> attached to the sidebar, but with a lower volume (50%), being just a > > >> background to the actual conversation. This would allow both B and D > > >> > > >> 2. then, the main conference mix is attached to it as 'sendonly' and > > >> with a -5dB gain to limit the volume of its own contribution to > > >> 30% (so that B and D can hear each other louder, while still > > >> listening to what's happening in the main conference in > > >> background); > > >> > > >> | | | B1. CONTROL (join confX-->confY) | > > >> | | |++++++++++++++++++++++++++++++++>>| > > >> | | | |--+ join confX > > >> | | | | | & confY > > >> | | | B2. 200 OK |<-+ sendonly > > >> | | |<<++++++++++++++++++++++++++++++++| (50% vol) > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> Of these, two references say 50% (-3dB) and two references say 30% or > > >> -5dB. > > >> > > > > > > > > > [LM] You're right, we'll make this consistent. > > > > > > > > >> item 30) section 6.3.5 figure 43 > > >> > > >> Is it intended that UAC (FCC) does not have any RTP going to the MS? > > >> (Indeed, is it necessarily a UAC? But perhaps SIP is needed to set up > > >> BFCP.) > > >> > > > > > > > > > [LM] Yes, to clarify the distinction between a simple participant and a > > > chair we chose to only display RTP for the participant, with the chair > > > moderating what happens on it. Whether or not the FCC has any RTP > > > flowing is not relevant to the example and that's why we omitted it. > > > That said, the chair does not need to be a UAC, you're right, and SIP is > > > not mandated to set up BFCP (RFC4583 is only a way to do so, BFCP just > > > talks of out of band mechanisms generally). We will remove the UAC for > > > the FCC in the figure to make this clearer. > > > > > > > > >> item 31) section 6.3.5 > > >> > > >> The participant UAC is labeled inconsistently as "UAC", "UAC (FCP)", > > >> and "UAC1". ("UAC" may be correct, as the context for that term my be > > >> describing a generic or abstract UAC.) Similarly, "UAC (FCC)" and > > >> "UAC2" are used for the chair UAC. > > >> > > > > > > > > > [LM] We'll fix the diagrams accordingly. > > > > > > > > >> item 32) section 6.3.5 > > >> > > >> It might be desirable to mention that the previous speaker should be > > >> muted before UAC1 can be un-muted. Usually, this muting will happen > > >> between the Accepted and Granted BFCP messages, so it probably should > > >> be illustrated in the sequence of events. > > >> > > > > > > > > > [LM] That's actually not needed, as BFCP does not force an exclusive > > > access to the resources it moderates. According to the policy in use, > > > several participants may be granted the same resource (e.g., ability to > > > talk) at the same time (e.g., in a conference bridge). > > > > > > > > >> item 33) section 6.4 > > >> > > >> It might be helpful to expand "VCR" the first time it is used. > > >> (Apparently it does not mean "video cassette recorder", and I see no > > >> suitable meaning on the Wikipedia "disambiguation" page for "VCR".) > > >> > > > > > > > > > [LM] We borrowed this terminology from RFC6231, the IVR Control Package. > > > The idea is to have "video cassette recorder"-lie controls, right, like > > > the ability to play, pause, stop, rewind, etc. We'll expand this. > > > > > > > > >> item 34) section 6.4.2 > > >> > > >> In fact, > > >> rather than having the AS build different framework messages > > >> according to the current time to build an announcement, > > >> > > >> This is difficult to read. Perhaps > > >> > > >> In fact, rather than having the AS build an announcement according > > >> to the current time using different framework messages, > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> item 35) section 6.4 > > >> > > >> The discussion of mixing in the background music should be contrasted > > >> with the mixing of the two recordings during playback in section > > >> 6.2.3. Naively, it would seem that the same mixing techniques could > > >> be used in both cases, but the two sections implement mixing in > > >> entirely different ways. > > >> > > > > > > > > > [LM] Are you talking of 6.4.2 (current time example)? If so, this was > > > done on purpose, to exploit two different scenarios to showcase the use > > > of two different techniques. You're right in saying that the same could > > > be applied to both cases, nothing naive in this :-) > > > > > > > > >> item 36) section 6.4.3 > > >> > > >> An example contains XML elements that seem to be unnecessarily > > >> complex: > > >> > > >> > > >> > > >> * > > >> > > >> > > >> > > >> > > >> As far as I can tell from the SRGS specification, functions > > >> more-or-less as a type of parenthesis, and is needed only when (1) a > > >> "weight" or "repeat" attribute needs to be applied to the group, (2) > > >> delimiting one alternative of a element, or (3) constructing > > >> the "null" regular expression (that consumes no input and always > > >> matches). Thus, these examples can be simplified to: > > >> > > >> > > >> * > > >> > > >> > > >> > > >> Then again, if the example is taken from a real interaction, perhaps > > >> it is best to leave it as it really happened. > > >> > > > > > > > > > [LM] I'm not an expert of SRGS, so I'm not sure about this. This is how > > > we implemented it in our Media Server, and it works this way, but it > > > would be nice to hear from other implementers to see if they usually > > > realize similar scenarios in a different way! > > > > > > > > >> item 37) section 6.4.3 > > >> > > >> to implement is a , and we are only interested in two- > > >> digits DTMF strings (maxdigits); the AS is not interested in a > > >> > > >> "two-digits" should be "two-digit". (Because this phrase is used as a > > >> modifier of "DTMF strings", the "digit" is not plural.) > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> instructs the MS into modifying the volume of the UAC-->conference > > >> > > >> "into modifying" would better be "to modify". > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> audio flow (setgain=-5dB sendonly); notice how the request also > > >> > > >> This is probably intended to be "-3dB", as all other uses of setgain > > >> in this section (including the displayed messages) use a 3 dB > > >> increment. > > >> > > > > > > > > > [LM] Right, we0ll make this consistent. > > > > > > > > >> item 38) section 6.4.3 > > >> > > >> This section leads to a question about the semantics of the > >> controltype="setgain" ...> operation: Clearly, initially the stream > > >> is output at the same volume as the input media. But when " > >> controltype='setgain' value='+1'>" is applied, does that cause the > > >> stream's output volume to be set to +1 dB *relative to the input > > >> media* or to +1 dB *relative to the previous volume setting*? > > >> > > >> E.g., if I apply that operation twice, does the second application > > >> leave the amplification at +1 dB or raise it to +2 dB? > > >> > > >> The examples in section 6.4.3 suggest the second interpretation. > > >> > > >> The text in draft-ietf-mediactrl-mixer-control-package-14 is not clear > > >> on this point: "setgain" is only discussed in section 4.2.2.5.1, and > > >> it says "use the value of the "value" attribute as a specific gain > > >> measured in dB to apply". That would be most likely to mean "as a > > >> specific gain measured in dB to apply to the input", which suggests > > >> the first interpretation. > > >> > > >> In any case, the semantics of this need to be clarified and the > > >> example adjusted accordingly. > > >> > > > > > > > > > [LM] If I recall correctly, when we first implemented this we discussed > > > it with the IVR authors during a meeting. If I'm not wrong the > > > conclusion was that setgain *sets* the gain, and does not modify the > > > previous value. I don't have the MS code in front of me right now, > > > though, I'll have to double check how we implemented this and let you > > > know. > > > > > > IVR authors, any insight on this from a specification point of view? > > > > > > > > >> item 39) section 7.1 > > >> > > >> Each MS makes use of the publishing interface to provide an MRB with > > >> relevant information. > > >> > > >> In the relationship between the MRB and MS, the MRB initiates the > > >> relationship. Thus, it would be clearer to express this: > > >> > > >> An MRB makes use of the MS's publishing interface to acquire > > >> relevant information. > > >> > > >> It is > > >> enough to point out that, in this case, the MRB adds a new voice to > > >> the 'Packages' it needs support for (mrb-publish/1.0). > > >> > > >> "voice" should be "item". > > >> > > >> All > > >> this messages flow through the control channel as all the messages in > > >> ---^^^^ > > >> should be "these" > > >> ----------------------------------------------------^ > > >> insert "do" > > >> this document. > > >> > > > > > > > > > [LM] Ok. > > > > > > > > >> item 40) section 7.1 message B1 > > >> > > >> This seems to be the only place in the draft where whitespace has been > > >> introduced where character content is valid, and so there is a > > >> question whether the draft needs to indicate that the whitespace would > > >> not be present on the wire. The relevant elements are: > > >> > > >> > > >> > > >> > > >> nbest > > >> > > >> > > >> > > >> > > >> single-view > > >> > > >> > > >> dual-view > > >> > > >> > > >> dual-view-crop > > >> > > >> > > >> dual-view-2x1 > > >> > > >> > > >> dual-view-2x1-crop > > >> > > >> > > >> quad-view > > >> > > >> > > >> multiple-5x1 > > >> > > >> > > >> multiple-3x3 > > >> > > >> > > >> multiple-4x4 > > >> > > >> > > >> > > >> > > >> I'm not sure if the schema defining urn:ietf:params:xml:ns:mrb-publish > > >> indicates that the whitespace before and after the mixing mode names > > >> is to be ignored. But this might be a place to use the > > >> backslash-line-folding convention specified in section 2: > > >> > > >> > > >> > > >> \ > > >> nbest \ > > >> > > >> > > >> > > >> \ > > >> single-view \ > > >> > > >> \ > > >> dual-view \ > > >> > > >> \ > > >> dual-view-crop \ > > >> > > >> \ > > >> dual-view-2x1 \ > > >> > > >> \ > > >> dual-view-2x1-crop \ > > >> > > >> \ > > >> quad-view \ > > >> > > >> \ > > >> multiple-5x1 \ > > >> > > >> \ > > >> multiple-3x3 \ > > >> > > >> \ > > >> multiple-4x4 \ > > >> > > >> > > >> > > >> > > > > > > > > > [LM] Yes, as I anticipated, we added that text to reflect a similar > > > comment you made when reviewing the MRB draft. This fix you suggest > > > makes sense, so we'll add it to the draft. > > > > > > > > >> item 41) section 7.1, section 7.2, section 7.2.1 > > >> > > >> In the Inline mode, instead, the MRB is in the > > >> path between the AS and the pool of MSs it is handling. > > >> > > >> Anyway, the MRB is also > > >> conceived to work with ASs that are unaware of its functionality, > > >> > > >> and the SIP addresses of the chosen MSs. > > >> > > >> Generally, "AS" and "MS" are used as the plurals of "AS" and "MS", but > > >> in these instances, "ASs" and "MSs" are used. > > >> > > > > > > > > > [LM] You're right, I fixed this in the MRB and not here, sorry. Besides, > > > ASs sounds really bad... :-) > > > > > > > > >> item 42) section 7.1 > > >> > > >> request itself and an SDP related to related to either the creation > > >> -----------------------------^^^^^^^^^^^^^^^^^^^^^ > > >> "related to" is duplicated. > > >> > > >> item 43) section 7.2.1 > > >> > > >> MS the MRB has deemed better capable to fulfill the AS requirements), > > >> -------------------------^^^^^^ > > >> This should be "best". > > >> -------------------------------------------------------^^ > > >> This should be "AS's" or "AS'" (depending on which spelling convention > > >> we are using). > > >> > > >> targeting the request, and as a consequence picks up two MS which > > >> --------------------------------------------------^^^^^^^^ > > >> I think you want "picks" here. > > >> > > >> after the Query the AS<->interaction becomes 1:1, UAC media dialogs > > >> ----------------------------^ > > >> Something appears to be missing here. > > >> > > > > > > > > > [LM] We'll fix them all. > > > > > > > > >> item 44) section 7.2.2.1, section 7.2.2.2, section 7.2.3 > > >> > > >> I think it would make the diagrams a little easier for the naive > > >> reader to follow if the media types specified in the SDP of the > > >> message bodies were given. E.g., if an INVITE or 200 carries an > > >> application/sdp body for audio media, that is shown on the diagram. > > >> This would be particularly helpful in 7.2.3, where it takes the reader > > >> more consideration to deduce what the media types must be. Updated in > > >> this way, the diagrams are as follows. (But this has removed the > > >> comments noting where the SDP has been copied from one message to > > >> another. That may need to be improved.) > > > > > > > > > [LM] Ok, we'll try and improve this to make it clearer. > > > > > > > > >> > > >> 7.2.2.1. Inline-aware Mode: CFW-based approach > > >> > > >> AS MRB MS > > >> | | | > > >> | 1. INVITE | | > > >> | (multipart/mixed: | | > > >> | audio, | | > > >> | application/mrb-consumer+xml) | > > >> |---------------------->| | > > >> | 2. 100 (Trying) | | > > >> |<----------------------| | > > >> | |--+ Extract SDP and | > > >> | | | MRB payloads; handle | > > >> | |<-+ Consumer request to | > > >> | | pick MS | > > >> | | | > > >> | | 3. INVITE | > > >> | | (audio) | > > >> | |-------------------------->| > > >> | | 4. 100 (Trying) | > > >> | |<--------------------------| > > >> | | |--+ Negotiate > > >> | | | | CFW Control > > >> | | |<-+ Channel > > >> | | 5. 200 OK | > > >> | | (audio) | > > >> | |<--------------------------| > > >> | | 6. ACK | > > >> | |-------------------------->| > > >> | Prepare new +--| | > > >> | payload with | | | > > >> | SDP from MS and +->| | > > >> | Consumer reply | | > > >> | | | > > >> | 7. 200 OK | | > > >> | (multipart/mixed: | | > > >> | audio, | | > > >> | application/mrb-consumer+xml) | > > >> |<----------------------| | > > >> | 8. ACK | | > > >> |---------------------->| | > > >> | | | > > >> |--+ Read Cons. reply | | > > >> | | and use SDP to | | > > >> |<-+ create CFW Chn. | | > > >> | | | > > >> | | > > >> |<<############## TCP CONNECTION #################>>| > > >> | | > > >> | CFW SYNC | > > >> |++++++++++++++++++++++++++++++++++++++++++++++++++>| > > >> | | > > >> > > >> 7.2.2.2. Inline-aware Mode: Media dialog-based approach > > >> > > >> UAC AS MRB MS > > >> | | | | > > >> | 1. INVITE | | | > > >> | (audio) | | | > > >> |-------------->| | | > > >> | 2. 100 Trying | | | > > >> |<--------------| | | > > >> | | 3. INVITE | | > > >> | | (multipart/mixed: | | > > >> | | audio, | | > > >> | | application/mrb-consumer_xml) | > > >> | |---------------------->| | > > >> | | 4. 100 (Trying) | | > > >> | |<----------------------| | > > >> | | |--+ Extract SDP and | > > >> | | | | MRB payloads; handle | > > >> | | |<-+ Consumer request to | > > >> | | | pick Media Servers | > > >> | | | | > > >> | | | 5. INVITE | > > >> | | | (audio) | > > >> | | |------------------------->| > > >> | | | 6. 100 (Trying) | > > >> | | |<-------------------------| > > >> | | | +--| > > >> | | | Handle media dialog | | > > >> | | | (connection-id) +->| > > >> | | | | > > >> | | | 7. 200 OK | > > >> | | | (audio) | > > >> | | |<-------------------------| > > >> | | | 8. ACK | > > >> | | |------------------------->| > > >> | | Prepare new +--| | > > >> | | payload with | | | > > >> | | SDP from MS and +->| | > > >> | | Consumer reply | | > > >> | | | | > > >> | | 9. 200 OK | | > > >> | | (multipart/mixed: | | > > >> | | audio, | | > > >> | | application/mrb-consumer+xml) | > > >> | |<----------------------| | > > >> | | 10. ACK | | > > >> | |---------------------->| | > > >> | | | | > > >> | |--+ Read Cons. reply | | > > >> | | | and send SDP | | > > >> | |<-+ back to UAC | | > > >> | 11. 200 OK | | | > > >> | (audio) | | | > > >> |<--------------| | | > > >> | 12. ACK | | | > > >> |-------------->| | | > > >> | | | | > > >> |<<*************************** RTP ******************************>>| > > >> | | | | > > >> | |--+ Negotiate | | > > >> | | | CFW channel | | > > >> | |<-+ towards MS | | > > >> | | (if needed) | | > > >> | | | | > > >> | |<<############## TCP CONNECTION ################>>| > > >> | | | > > >> | | CFW SYNC | > > >> | |+++++++++++++++++++++++++++++++++++++++++++++++++>| > > >> | | | > > >> > > >> 7.2.3. Inline-unaware Mode > > >> > > >> AS MRB MS > > >> | | | > > >> | 1. INVITE | | > > >> | (application/cfw) | | > > >> |---------------------->| | > > >> | 2. 100 (Trying) | | > > >> |<----------------------| | > > >> | |--+ Pick a MS | > > >> | | | and redirect | > > >> | |<-+ INVITE there | > > >> | | | > > >> | | 3. INVITE | > > >> | | (application/cfw) | > > >> | |-------------------------->| > > >> | | 4. 100 (Trying) | > > >> | |<--------------------------| > > >> | | |--+ Negotiate > > >> | | | | CFW Control > > >> | | |<-+ Channel > > >> | | 5. 200 OK | > > >> | | (application/cfw) | > > >> | |<--------------------------| > > >> | | 6. ACK | > > >> | |-------------------------->| > > >> | | | > > >> | 7. 200 OK | | > > >> | (application/cfw) | | > > >> |<----------------------| | > > >> | 8. ACK | | > > >> |---------------------->| | > > >> | | | > > >> | | > > >> |<<############## TCP CONNECTION #################>>| > > >> | | > > >> | CFW SYNC | > > >> |++++++++++++++++++++++++++++++++++++++++++++++++++>| > > >> | | > > >> > > >> item 45) section 7.2.2 > > >> > > >> An AS willing to issue a Concumer request by means of SIP, has to do > > >> ----------------------------^ > > >> This should be "Consumer". > > >> > > >> envisages two kind of SIP dialogs a Consumer request may be sent > > >> -----------------^ > > >> This should be "kinds". > > >> > > >> setup a control channel) or a UAC media dialog (a SIP dialog the AS > > >> ---^ > > >> This should be "set up". ("set up" functions like a verb; "setup" > > >> functions like a noun.) > > >> > > >> The behaviour in the two cases, which are called respectively CFW- > > >> -------^ > > >> Probably better to say "behaviours" here. > > >> based and Media dialog-based approach, is only slightly different, > > >> ------------------------------------------^ > > >> Use "are", to go with "behaviors". > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> item 46) section 7.2.2.1, section 7.2.2.2 > > >> > > >> Please note that, to ease the reading of the protocol contents, a > > >> simple '=_Part' is used whenever a boundary for a 'multipart/mixed' > > >> payload is provided, instead of the actual boundary that would be > > >> inserted in the SIP messages. > > >> > > >> This seems like a poor strategy, as the resulting figures are not > > >> strictly correct. Perhaps use "Part" as the boundary value, which > > >> would result in figures that look like the following, which strictly > > >> correct and are just as easy to read: > > >> > > >> [..] > > >> Content-Type: multipart/mixed;boundary="Part" > > >> > > >> --Part > > >> Content-Type: application/sdp > > >> > > >> v=0 > > >> o=- 2890844526 2890842807 IN IP4 as.example.com > > >> [...] > > >> > > >> --Part > > >> Content-Type: application/mrb-consumer+xml > > >> > > >> > > >> > >> xmlns="urn:ietf:params:xml:ns:mrb-consumer"> > > >> [...] > > >> > > >> > > >> --Part-- > > >> > > > > > > > > > [LM] I think we did it this way after a comment received on the list: > > > Chris and I did the same for the examples in the MRB draft, for instance. > > > If you think it might improve the readibility of the document we'll > > > change this. > > > > > > > > >> In both of these sections, just before the message listings, there is > > >> a line containing only: > > >> > > >> o > > >> > > > > > > > > > [LM] Probably a leftover, we'll remove it. > > > > > > > > >> In the following message titles, "SDP" appears in lower case: > > >> > > >> section 7.2.2.1: > > >> 3. MRB -> MS (INVITE sdp only) > > >> 5. MRB <- MS (200 OK sdp) > > >> section 7.2.2.2: > > >> 5. MRB -> MS (INVITE sdp only) > > >> 7. MRB <- MS (200 OK sdp) > > >> 11. UAC <- AS (200 OK sdp) > > >> > > >> item 47) section 7.2.3 > > >> > > >> pick a MS rather than another. > > >> --------^ > > >> Probably should be "one", to contrast with "another". > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> item 48) section 7.2.3 > > >> > > >> This example does not give the content of the messages, unlike the > > >> previous two examples. > > >> > > > > > > > > > [LM] It's because in the IUMM mode no Consumer transaction is involved. > > > It's a normal RFC6230 Control Channel negotiation where the MRB acts > > > as an intermediary, that is, picking a MS for the AS according to some > > > logic. In this case, in fact, the AS does not support the MRB > > > specification, and so just tries to set up a control channel the way > > > it knows. > > > > > > > > >> item 49) section 7.3.1 > > >> > > >> This section is titled "Query/IAMM". The call flow does mesh with the > > >> call flow in section 7.2.1, "Query Mode", but it does not mesh with > > >> the call flow in section 7.2.2.1, "Inline-aware Mode: CFW-based > > >> approach" nor with the call flow in section 7.2.2.2, "Inline-aware > > >> Mode: Media dialog-based approach". > > >> > > >> It would probably be best to change the title of the section to > > >> "Query". If necessary, an additional section should be added giving > > >> examples relevant to inline-aware mode. > > >> > > >> item 50) section 7.3.1, section 7.3.2 > > >> > > >> The use of "IAMM" and "IUMM" is a bit opaque here, as those acronyms > > >> are not explicitly expanded anywhere in this document. They seem to > > >> mean what is called "inline-aware mode" and "inline-unaware mode", but > > >> the acronyms of those phrases aren't the same as the acronyms used. > > >> > > >> Perhaps these section titles could be changed to resemble those of > > >> 7.2.*, "7.3.1. Query and Inline-aware Mode" and "7.3.2. Inline-unaware > > >> Mode". That doesn't fix the problem with the acronyms per se but does > > >> make the titles clearer. > > >> > > > > > > > > > [LM] You're right about both comments, we'll try to make this clearer > > > and more consistent across the document. > > > > > > > > >> item 51) section 7.3.1 > > >> > > >> We might want to mention that in this scenario, the AS obtains > > >> assignment of an MS *before* any UAC makes a request, in order to have > > >> facilities to satisfy future SIP requests. That is probably how AS's > > >> operate in practice, but a naive reader might expect that the AS will > > >> make the consumer request only after the AS receives a demand for its > > >> services. > > > > > > > > > [LM] Actually both Fig.53 and 54 show the AS creating a control channel > > > before receiving an INVITE from the UAC. Or was your point about a > > > different aspect? > > > > > > > > >> > > >> Nevertheless, there are cases when having an MRB in the signalling > > >> path ... > > >> > > >> You might want to say "the SIP signalling path" here. By my count, > > >> there are *three* different signalling paths: the COMEDIA negotiation > > >> (INVITE with application/cfw SDP), the CFW connection, and the SIP > > >> signalling (INVITE with audio/etc. SDP). > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> item 52) section 7.3.2 > > >> > > >> As mentioned previously, in such a case the AS would interact with > > >> What case is "in such a case"? (This is the first sentence of a > > >> section.) It seems that this paragraph is trying to contrast "such a > > >> case" with "IUMM", but it's not clear what is going on. > > >> > > > > > > > > > [LM] It's referring to the case described by the section title, which is > > > a poor editing choice. We'll make this more explicit. > > > > > > > > >> That said, the IUMM case is also very interesting with respect to the > > >> media dialogs management. In fact, in the MRB-unaware mode there > > >> ---------^ > > >> This should be "dialog". > > > > > > > > > [LM] OK. > > > > > > > > >> would be no Consumer request and an AS would actually see the MRB as > > >> an MS. This means that, unlike the previous scenarios, there is > > >> actually no choice, meaning the MRB would likely be in the signaling > > >> ------------^ > > >> What is there "no choice" of? The obvious choice is that of a MS, but > > >> the MRB clearly can choose which MS to sent the request to. > > > > > > > > > [LM] Probably a poorly translated sentence, as this makes more sense in > > > Italian. The sentence is trying to say that there is no active selection > > > process driven by an AS<->MRB interaction so yes, something eventually > > > leading to choosing a specific MS according to that. That's why the > > > document then explains a potential approach to take care of this. > > > > > > > > >> path anyway. The MRB could either redirect the AS to a MS directly > > >> or transparently act a proxy/B2BUA and contact a MS (according to > > >> implementation-specific policies) on behalf of the unaware AS. > > >> > > >> To overcome the scalability limitations of such an approach, the MR > > >> --------------------------------------------------------------^ > > >> You should add here "at least in regard to the MRB being in the SIP > > >> signalling path for all calls" -- as far as I can tell, this is the > > >> only scaling problem this approach removes. (The major one is that > > >> all calls handled by the AS have to be handled by only one MS.) > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> Rather than recurring to explicit redirection, or always > > >> ---------------^ > > >> This isn't the right word. Perhaps "resorting" was intended? > > >> > > > > > > > > > [LM] Yes, we'll fix this. > > > > > > > > >> item 53) section 7.3.2 > > >> > > >> While apparently not a problem, this raises an issue when the same > > >> unaware AS has several sessions with different MS: the AS would only > > >> see one "virtual" MS (the MRB) and so it would relay all calls there, > > >> making it hard for the MRB to understand where these media dialogs > > >> should belong: specifically, whether the UAC calling belongs to the > > >> AS application logic leading to MS1 or MS2, or wherever else. > > >> > > >> This seems to be a deficiency in the CFW protocol: If the AS > > >> establishes a CFW channel with the MS (via a SIP URI to an MRB), and > > >> then later the AS wants to addresses a SIP INVITE to the MS, it has no > > >> choice but to use the same SIP URI (which routes to the MRB). This > > >> makes it impossible for the MRB to associate the SIP INVITE with the > > >> CFW connection, and thus it is difficult for the MRB to route the > > >> INVITE to the same MS. > > >> > > >> What seems to be needed is for either the COMEDIA response > > >> (application/cfw) or CFW connection to provide a SIP URI that is the > > >> "real" SIP URI of the far-end of the CFW channel. > > >> > > >> Actually, this seems to be a problem even if an AS is addressing an MS > > >> URI, but the URI resolves to a redundant set of MSs: There seems to > > >> be no way to ensure that when a CFW channel is established that a > > >> subsequent SIP INVITE can be sent to the same MS. This issue seems to > > >> be discussed in RFC 6230 section 3, but I can't find any solution > > >> there. > > >> > > > > > > > > > [LM] The way it works now is that, for a specific MS, the same SIP URI > > > is used for both negotiating a control channel and attaching media > > > dialogs, yes. A way to overcome this may having the MS redirect media > > > dialogs to a different SIP URI when it receives them (that is, treat > > > control and media dialogs differently) but I realize how this sounds > > > like an implementation hack rather than a real solution. > > > > > > > > >> item 54) section 8 > > >> > > >> receiving requests that may cross the bounds each AS is constrained > > >> into. > > >> ---^ > > >> Probably better as "within". > > >> > > > > > > > > > [LM] OK. > > > > > > > > >> item 55) section 8 > > >> > > >> The detailed discussion of how the MS enforces security against the > > >> ASs is helpful, but it does not mention how the MS discerns which > > >> requests come from AS1 and which come from AS2. > > >> > > >> Dale > > > > > > > > > [LM] Thanks again for your detailed review: this is exactly the kind of > > > thorough feedback we were looking for, as so far we had to rely on our > > > own, a bit biased and probably not very objective review process :-) > > > > > > Lorenzo > > > > > > > > >> _______________________________________________ > > >> MEDIACTRL mailing list > > >> MEDIACTRL@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mediactrl > > >> Supplemental Web Site: > > >> http://www.standardstrack.com/ietf/mediactrl > > > > > > > > > -- > > > Lorenzo Miniero, COB > > > > > > Meetecho s.r.l. > > > Web Conferencing and Collaboration Tools > > > http://www.meetecho.com > > > _______________________________________________ > > > MEDIACTRL mailing list > > > MEDIACTRL@ietf.org > > > https://www.ietf.org/mailman/listinfo/mediactrl > > > Supplemental Web Site: > > > http://www.standardstrack.com/ietf/mediactrl > > > > > -- > Lorenzo Miniero, COB > > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From worley@shell01.TheWorld.com Mon Apr 15 07:16:14 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251D021F9440 for ; Mon, 15 Apr 2013 07:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1NEjarpwvjf for ; Mon, 15 Apr 2013 07:16:13 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7356521F93F3 for ; Mon, 15 Apr 2013 07:16:12 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r3FEG24Y000911 for ; Mon, 15 Apr 2013 10:16:04 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3FEFxRj2677434 for ; Mon, 15 Apr 2013 10:16:01 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3FEFxIu2677502; Mon, 15 Apr 2013 10:15:59 -0400 (EDT) Date: Mon, 15 Apr 2013 10:15:59 -0400 (EDT) Message-Id: <201304151415.r3FEFxIu2677502@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mediactrl@ietf.org In-reply-to: <0A241228-2798-42D3-B03C-BF896BBC267F@standardstrack.com> (eburger@standardstrack.com) References: <20130411214409.51DDEB1E003@rfc-editor.org> <0A241228-2798-42D3-B03C-BF896BBC267F@standardstrack.com> Subject: Re: [MEDIACTRL] RFC 6917 on Media Resource Brokering X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:16:14 -0000 > From: Eric Burger > > PAR-TAY!!!! > > Excellent work, all. > > On Apr 11, 2013, at 5:44 PM, rfc-editor@rfc-editor.org wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 6917 > > > > Title: Media Resource Brokering > > Author: C. Boulton, L. Miniero, > > G. Munson > > Status: Standards Track > > Stream: IETF > > Date: April 2013 > > Mailbox: chris@ns-technologies.com, > > lorenzo@meetecho.com, > > gamunson@gmail.com > > Pages: 136 > > Characters: 280399 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-mediactrl-mrb-19.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc6917.txt Thanks to everyone who has worked so hard on this! Dale From worley@shell01.TheWorld.com Mon Apr 15 14:50:05 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FCB21F9408 for ; Mon, 15 Apr 2013 14:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FR_DOT_FEVER_5=3.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKH2mISByR5w for ; Mon, 15 Apr 2013 14:50:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id CADB321F93F9 for ; Mon, 15 Apr 2013 14:50:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r3FLmLw6024615 for ; Mon, 15 Apr 2013 17:48:23 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r3FLmKaM2683903 for ; Mon, 15 Apr 2013 17:48:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r3FLmKaO2695748; Mon, 15 Apr 2013 17:48:20 -0400 (EDT) Date: Mon, 15 Apr 2013 17:48:20 -0400 (EDT) Message-Id: <201304152148.r3FLmKaO2695748@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: mediactrl@ietf.org In-reply-to: <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> (eburger@standardstrack.com) References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 21:50:05 -0000 > From: Eric Burger > > Are we done yet? Looking over the messages, I see that I should have responded to Lorenzo's message of 26 Dec (http://www.ietf.org/mail-archive/web/mediactrl/current/msg01781.html). Of course, most of the items have already been resolved, but there are a few that need more discussion. > > item 1) various > > > > The indentation of the header lines identifying various messages is > > inconsistent. I can find the following lines in various places: > [...] > > [LM] You're right, the indentation often varies, and the logic behind > this currently is according to whether or not the example fits the page. > Instructions about this would be welcome! I think leaving it to the Editor may be the best, and the Editor will have to worry about fitting the lines on the page anyway. The Editor probably as style conventions about indenting. > > item 2) various > > > > There are a lot of places where an arrow seems to go from a network > > entity to itself, such as "create conf and its ID" below: > > > > AS MS > > | | > > | 1. CONTROL (create conference) | > > |++++++++++++++++++++++++++++++++>>| > > | |--+ create > > | | | conf and > > | 2. 200 OK (conferenceid=Y) |<-+ its ID > > |<<++++++++++++++++++++++++++++++++| > > [LM] Yes, in that case the arrow was not meant as a network connection, > but as a further step in the sequence diagram, that is what that > CONTROL message triggers in the MS application logic. The same applies > to all the examples where this happens. If you think the arrowless > diagram is clearer to the reader we might remove them: the problem with > this is that, without arrows, some diagrams might be harder to read, > i.e., in terms of who does what in diagrams with several components > interacting with each other. As an alternative, we might clarify what > those arrows are and what they are not. What do you think about this? We might be able to choose a syntax that less resembles the propagation of a message. Perhaps this: AS MS | | | 1. CONTROL (create conference) | |++++++++++++++++++++++++++++++++>>| | |-- create | | conf and | | its ID | 2. 200 OK (conferenceid=Y) | |<<++++++++++++++++++++++++++++++++| That makes it clear that the MS is performing an action, but it does not look like generating a message. > > item 7) section 4 > > > > This section starts with a paragraph over one page long. Could it be > > broken into multiple paragraphs? > > [LM] Did you mean section 4.1? Section 4 starts with just a few lines. Yes, you are right, I meant section 4.1. > > item 9) section 4 figure 1 > > [...] > > - The states "'202' sent" and "'update' sent" have the same outgoing > > transitions, so they should probably be merged. > > [LM] I'm not sure about this: 202 is only sent after the first CONTROL > message to tell the AS it may take a while to process the request, after > which you can either have further 202 messages should the processing > take even more time, or one or more UPDATE messages related to that > CONTROL request after that. They're two different messages in the > protocol semantics. Nevertheless, it's also true that, according to > RFC6230, a 202 is basically a pre-REPORT message... any feedback on > this? The idea is that the MS is in the same state after sending the 202 as it is after sending a subsequent update, because what it can do next is the same, and so at least theoretically, the two states do not need to be distinguished. My idea is that the diagram could be simplified to look like this: +------------------+ CONTROL/- +------------------+ API 202/202 | Idle/'terminate' |------------>| CONTROL received |---------+ +------------------+ +------------------+ | ^ ^ ^ | | | | | | API 200/200 | | | | | +------------------+ | | | 200/- | API Error/Error | | | +----------------------------+ | | | | | | API terminate/ v +------------------+ REPORT terminate +-------------------+ | 'terminate' sent |<--------------------------| command executing | +------------------+ +-------------------+ ^ | | | API update/ | | REPORT update | | | | | | 200/- | | | v +---------------+ | 'update' sent | +---------------+ > > item 9) section 4 figure 1 > > [...] > > - What happens if the API detects an error after 202 has been sent? > > There is no "API Error" arc from "'202' sent"/"'update' confirmed". > > [LM] Good point. The idea is that, once the MS sends a 202, the request > has been correctly processed, and so is supposed to be fine as far as > the protocol is concerned. I guess there could be circumstances when an > errors occurs after that, e.g., in retrieving an audio file to be played > to a UAC: in that case, the AS would be informed of the termination of > the dialog/request in a REPORT terminate, including details on the issue > which are Control Package specific. Do you think explaining this in the > text may help readers? I think an explanation in the text would be helpful, although if the reader has a thorough understanding of what information is carried in REPORT terminate they would deduce the answer. Perhaps this explanation would help those who are not completely familiar: The MS may send a 202 response after it determines that the request request contains no errors that cannot be reported in a later REPORT terminate request. After the MS sends a 202 response, any error that it (or the API) finds in the request is reported in the final REPORT terminate request. > > item 12) section 5 > > > > The term "COMEDIA" is used, and a reference is given to RFC 4145. But > > that RFC does not use the term "COMEDIA" at all. The framework I-D > > also uses "COMEDIA" without explicitly defining it. It would be > > helpful to insert here a definition of "COMEDIA", which seems to be > > synonymous with "media of type application/cfw". > > [LM] I thought COMEDIA actually came from RFC4145, standing for > "connection-oriented media". Even the MSRP RFC refers to it that way. If > that's incorrect or incomplete we'll fix this in the next version. I've searched through all the RFCs for the term "comedia". (The results are summarized at the end of this message.) What seems to have happened is that "comedia" has become an abbreviation for "connection-oriented media" (i.e., TCP and TLS) and also for two RFCs regarding support for connection-oriented media (RFC 4145 and RFC 4572). The problem is that the term seems to be very common among a small audience centered on Mediactrl, but only among that audience, and people inside that audience do not take care to define it clearly for the benefit of people outside that audience. For instance, RFC 5567 is "An Architectural Framework for Media Server Control" and uses "comedia" in "... exploit floor control by means of a Connection-Oriented Media (COMEDIA) [RFC4145] negotiation." but "comedia" is not listed in its section 2, "Terminology". I think this would be solved if "comedia" was listed in section 3, "Terminology": COMEDIA: connection-oriented media (i.e., TCP and TLS). Also used to signify the support in SDP for connection-oriented media, and the RFCs that define that support (RFC 4145 and RFC 4572). > > item 15) section 5.1 > > > [...] > > This confuses me: Either the list of packages in the SDP offer/answer > > is significant or it is not. If it is not, why is it provided? > > [...] > > [LM] That section refers to a draft Chris submitted to the MMUSIC WG > some time ago: > > http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07 > > so any clarification about the purpose and constraints of such a > mechanism should be addressed in the specification. Chris, do you think > this behaviour could be clarified in the draft, in order to have it > reflected in the Call Flows as a consequence? This looks complicated. It seems that draft-boulton-mmusic-sdp-control-package-attribute has not been adopted as a working group draft and has expired. If that is the case, there will be no definition of the ctrl-package attribute, and it shouldn't be used in the call-flows. But if that is fixed, it seems that we can copy some text from draft-boulton-mmusic-sdp-control-package-attribute to clarify this paragraph. I suggest splitting the paragraph, and amending the second half like this: Note that the provided example also includes the indication, from both the AS and the MS, of the supported control packages. This is achieved by means of a series of 'ctrl-package' attributes as specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. In the example, the AS supports (or is only interested to) two packages: IVR (Interactive Voice Response) and Mixer (Conferencing and Bridging). The MS replies with the list of packages it supports, adding a dummy example package to the list provided by the AS. It is worth noting that this exchange of information is only advisory and neither endpoint is committing to support the packages that are listed or to not supporting the packages that are not listed. The actual negotiation of control packages is done subsequently through the use of the framework SYNC transaction within the control channel. Nonetheless, the use of 'ctrl-package' attributes can be beneficial both from a resource allocation perspective and it could also result in two clients identifying they are not capable of successful control channel interactions. This would lead to early abandonment of control channel setup (for example, a client may choose to terminate the associated SIP dialog and not attempt to make the connection). > > item 17) section 5.3 > > > > In the previous section it has been described how a timeout value for > > the keep alive mechanism is negotiated. Specifically, in the example > > the AS and the MS agreed on a value of 100 seconds. > > > > In fact, that section does not describe how the value is negotiated > > (since it is not clear what happens if the MS dislikes the value > > proposed by the AS). However, this is correct: > > > > In example in the previous section, the AS and the MS agreed on a > > value of 100 seconds. > > [LM] According to RFC6230, the 200 to the SYNC MUST have the same > keep-alive value proposed in the original SYNC. Who sends the SYNC can > change according to the COMEDIA negotiation. Specifically, "The previous > steps ensure that the entity initiating the Control Channel connection > is always the one specifying the keep-alive timeout period.". So, to > answer your question, I guess that if a MS dislikes the value, it can > just pick the active role and send a new SYNC with a new keep-alive > value. OK, that was my mistake, as I was confusing how the MRB mechanism works with the more complicated SIP timeout mechanism. But I think it could be clarified by changing the two sentences to: In the previous section it has been described that the timeout value for the keep-alive mechanism is set by the SYNC request. Specifically, in the example the AS specified a value of 100 seconds. In particular, the timeout value is not *negotiated* between the AS and MS, it is simply specified by whichever endpoint takes the active role. > > item 22) section 6.1.2 > > > > The 202+REPORT(s) mechanism is used whenever the MS wants to tell > > the AS that the requested operation might take some more time than > > expected. > > [LM] Actually, the time is Control Package dependent. Different packages > may have different timeouts. Quoting the framework, "A Control Package > MUST explicitly define the circumstances under which the server sends > 200 and 202 messages." Then the situation could be made clearer by writing: The 202+REPORT(s) mechanism is used whenever the MS wants to tell the AS that the requested operation might take more time than the limit specified in the definition of the Control Package. > > item 23) section 6.2 figure 18 > > > > It might be useful to distinguish the four(?) SIP dialogs involved. > > [LM] Do you mean as in different figures? or clearer text? I made a mistake there; I should have said "figure 17". The figure is a bit confusing, as there are either 3 or 4 SIP dialogs involved, and the SIP messages are not marked to show which dialog they are within. (Depending on how the AS functions, the SIP from UAC2 to AS may or may not be within the same dialog as the SIP from UAC1 to AS.) Someone familiar with AS/MS operation can guess which messages are part of which dialogs, but it may be confusing for those who are not familiar. It might not be important in this context, but in RFCs that come out of the SIP WGs, in a situation like this, the different SIP dialogs are distinguished by specifying Call-Id values. In this case, figure 17 would look like this: UAC(1) UAC(2) AS MS | | | | | INVITE (offer A) | | | Call-Id: A | | | |---------------------------------->| | | | 100 Trying | | | | Call-Id: A | | |<----------------------------------| | | | INVITE (no offer) | | | | Call-Id: B | | | |<--------------------| | | | 180 Ringing | | | | Call-Id: B | | | |-------------------->| | | | 180 Ringing | | | | Call-Id: A | | |<----------------------------------| | | | | INVITE (offer A) | | | | Call-Id: C | | | |-------------------------->| | | | 200 OK (offer A') | | | | Call-Id: C | | | |<--------------------------| | | | ACK | | | | Call-Id: C | | | |-------------------------->| | | 200 OK (offer B) | | | | Call-Id: B | | | |-------------------->| | | | | INVITE (offer B) | | | | Call-Id: D | | | |-------------------------->| | | | 200 OK (offer B') | | | | Call-Id: D | | | |<--------------------------| | | | ACK | | | | Call-Id: D | | | |-------------------------->| | | ACK (offer B') | | | | Call-Id: B | | | |<--------------------| | | | 200 OK (offer A') | | | | Call-Id: A | | |<----------------------------------| | | ACK | | | | Call-Id: A | | | |---------------------------------->| | | | | | . . . . . . . . (If the AS acts like a proxy between UAC1 and UAC2 rather than a B2BUA, then "Call-Id: B" is replaced with "Call-Id: A" throughout.) > > item 35) section 6.4 > > > > The discussion of mixing in the background music should be contrasted > > with the mixing of the two recordings during playback in section > > 6.2.3. Naively, it would seem that the same mixing techniques could > > be used in both cases, but the two sections implement mixing in > > entirely different ways. > > [LM] Are you talking of 6.4.2 (current time example)? If so, this was > done on purpose, to exploit two different scenarios to showcase the use > of two different techniques. You're right in saying that the same could > be applied to both cases, nothing naive in this :-) OK, I see the point of the example. But I see another issue: It might help to add to section 3: VCR controls: runtime control of aspects of an audio playback like speed and volume, via DTMF signals sent by the user, in a manner that resembles the functions of a VCR (video cassette recorder) controller. > > item 36) section 6.4.3 > > > > An example contains XML elements that seem to be unnecessarily > > complex: > > > > > > > > * > > > > > > > > > > As far as I can tell from the SRGS specification, functions > > more-or-less as a type of parenthesis, and is needed only when (1) a > > "weight" or "repeat" attribute needs to be applied to the group, (2) > > delimiting one alternative of a element, or (3) constructing > > the "null" regular expression (that consumes no input and always > > matches). Thus, these examples can be simplified to: > > > > > > * > > > > > > > > Then again, if the example is taken from a real interaction, perhaps > > it is best to leave it as it really happened. > > [LM] I'm not an expert of SRGS, so I'm not sure about this. This is how > we implemented it in our Media Server, and it works this way, but it > would be nice to hear from other implementers to see if they usually > realize similar scenarios in a different way! Yes, let us ask implementers what they think is clearer. > > item 38) section 6.4.3 > > > > This section leads to a question about the semantics of the > controltype="setgain" ...> operation: Clearly, initially the stream > > is output at the same volume as the input media. But when " > controltype='setgain' value='+1'>" is applied, does that cause the > > stream's output volume to be set to +1 dB *relative to the input > > media* or to +1 dB *relative to the previous volume setting*? > > > > E.g., if I apply that operation twice, does the second application > > leave the amplification at +1 dB or raise it to +2 dB? > > > > The examples in section 6.4.3 suggest the second interpretation. > > > > The text in draft-ietf-mediactrl-mixer-control-package-14 is not clear > > on this point: "setgain" is only discussed in section 4.2.2.5.1, and > > it says "use the value of the "value" attribute as a specific gain > > measured in dB to apply". That would be most likely to mean "as a > > specific gain measured in dB to apply to the input", which suggests > > the first interpretation. > > > > In any case, the semantics of this need to be clarified and the > > example adjusted accordingly. > > [LM] If I recall correctly, when we first implemented this we discussed > it with the IVR authors during a meeting. If I'm not wrong the > conclusion was that setgain *sets* the gain, and does not modify the > previous value. I don't have the MS code in front of me right now, > though, I'll have to double check how we implemented this and let you > know. > > IVR authors, any insight on this from a specification point of view? Now that I think about it more, I think the usual terminology is that the gain is seen as the difference between the input and the output, and "setting" it means fixing the gain at a specific number. However, in many usages, a number prefixed by "+" or "-" is used to mean an increment/decrement relative to the previous value. What misleads me is that the setgain operations are shown as implementations of the *1 and *9 requests, which are *incremental*. The possibility of misunderstanding could be removed by adding a comment. (Also, I think that each bullet point should be shown as sentences, that is, starting with a capital letter and ending with a period, rather than many clauses separated by ";". Here, I have left the paragraphs un-filled to make my change clearer; you probably want to fill the entire bullet point.) o The AS ACKs the event (B2), and in its business logic understands that the code '*1' means that the UAC wants its own volume to be lowered in the conference mix. The AS is able to associate the event with the right UAC by referring to the attached dialogid (01d1b38). It then acts accordingly, by sending a (C1) which does exactly this: the provided child element instructs the MS to modify the volume of the UAC-->conference audio flow (setgain=-5dB sendonly). Notice that the "setgain" value is the absolute volume level; if the user's request is to lower the volume level, the AS must remember the previously set volume level and from it calculate the new volume level. Notice how the request also includes directives upon the inverse direction. This verbose approach is needed, since otherwise the MS would not only change the volume in the requested direction, but also disable the media flow in the other direction; having a proper addressing the UAC<--conf media flow as well ensures that this doesn't happen. Since we have clarified the situation with the first "setgain", there is no need to repeat the clarification for the second "setgain". > > item 41) section 7.1, section 7.2, section 7.2.1 > > [...] > > Generally, "AS" and "MS" are used as the plurals of "AS" and "MS", but > > in these instances, "ASs" and "MSs" are used. > > [LM] [...] Besides, ASs sounds really bad... :-) Ah, yes, I overlooked that. :-) > > item 46) section 7.2.2.1, section 7.2.2.2 > > > > Please note that, to ease the reading of the protocol contents, a > > simple '=_Part' is used whenever a boundary for a 'multipart/mixed' > > payload is provided, instead of the actual boundary that would be > > inserted in the SIP messages. > > > > This seems like a poor strategy, as the resulting figures are not > > strictly correct. Perhaps use "Part" as the boundary value, which > > would result in figures that look like the following, which strictly > > correct and are just as easy to read: > > > > [..] > > Content-Type: multipart/mixed;boundary="Part" > > > > --Part > > Content-Type: application/sdp > > > > v=0 > > o=- 2890844526 2890842807 IN IP4 as.example.com > > [...] > > > > --Part > > Content-Type: application/mrb-consumer+xml > > > > > > > xmlns="urn:ietf:params:xml:ns:mrb-consumer"> > > [...] > > > > > > --Part-- > > [LM] I think we did it this way after a comment received on the list: > Chris and I did the same for the examples in the MRB draft, for instance. > If you think it might improve the readability of the document we'll > change this. I can't find the message that you mention, although the change is clear between draft-ietf-mediactrl-mrb-03 and -04. For example: 1. AS -> MRB (INVITE multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed; \ boundary="----=_Part_0_19138361.1261662356915" ------=_Part_0_19138361.1261662356915 Content-Type: application/sdp v=0 becomes 1. AS -> MRB (INVITE multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed;boundary="=_Part" =_Part Content-Type: application/sdp v=0 But you could make the example both easy to read and formally correct by just using "Part" as the boundary value (because no body line starts with "--Part"): 1. AS -> MRB (INVITE multipart/mixed) ------------------------------------- [..] Content-Type: multipart/mixed;boundary="Part" --Part Content-Type: application/sdp v=0 > > item 51) section 7.3.1 > > > > We might want to mention that in this scenario, the AS obtains > > assignment of an MS *before* any UAC makes a request, in order to have > > facilities to satisfy future SIP requests. That is probably how AS's > > operate in practice, but a naive reader might expect that the AS will > > make the consumer request only after the AS receives a demand for its > > services. > > [LM] Actually both Fig.53 and 54 show the AS creating a control channel > before receiving an INVITE from the UAC. Or was your point about a > different aspect? I think my point was that you might want to call out in the text that the AS creates a control channel to a chosen MS *before* it has any requests to service. > > item 53) section 7.3.2 > > > > While apparently not a problem, this raises an issue when the same > > unaware AS has several sessions with different MS: the AS would only > > see one "virtual" MS (the MRB) and so it would relay all calls there, > > making it hard for the MRB to understand where these media dialogs > > should belong: specifically, whether the UAC calling belongs to the > > AS application logic leading to MS1 or MS2, or wherever else. > > > > This seems to be a deficiency in the CFW protocol: If the AS > > establishes a CFW channel with the MS (via a SIP URI to an MRB), and > > then later the AS wants to addresses a SIP INVITE to the MS, it has no > > choice but to use the same SIP URI (which routes to the MRB). This > > makes it impossible for the MRB to associate the SIP INVITE with the > > CFW connection, and thus it is difficult for the MRB to route the > > INVITE to the same MS. > > > > What seems to be needed is for either the COMEDIA response > > (application/cfw) or CFW connection to provide a SIP URI that is the > > "real" SIP URI of the far-end of the CFW channel. > > > > Actually, this seems to be a problem even if an AS is addressing an MS > > URI, but the URI resolves to a redundant set of MSs: There seems to > > be no way to ensure that when a CFW channel is established that a > > subsequent SIP INVITE can be sent to the same MS. This issue seems to > > be discussed in RFC 6230 section 3, but I can't find any solution > > there. > > [LM] The way it works now is that, for a specific MS, the same SIP URI > is used for both negotiating a control channel and attaching media > dialogs, yes. A way to overcome this may having the MS redirect media > dialogs to a different SIP URI when it receives them (that is, treat > control and media dialogs differently) but I realize how this sounds > like an implementation hack rather than a real solution. If an AS is contacting an MS directly, then there is not much of a problem with the AS using the same URI for negotiating CFW and for establishing SIP dialogs. But if the AS is contacting an MRB and the MRB is contacting an MS, when the MRB receives the SIP INVITE, it must be able to determine that the AS wants to have the INVITE forwarded to the same MS to which the MRB forwarded the CFW previously. How does the MRB determine that the AS intends the INVITE to go to the same destination as a particular CFW channel? > > item 55) section 8 > > > > The detailed discussion of how the MS enforces security against the > > ASs is helpful, but it does not mention how the MS discerns which > > requests come from AS1 and which come from AS2. I did not see a response to this issue. ---------------------------------------------------------------------- Summary of uses of "comedia" in published RFCs RFC 4145 does not contain the term "comedia" at all, although its short title is "Connection-Oriented Media". RFC 4571 uses "comedia" only as the name of a Normative Reference to RFC 4145. RFC 4572 uses "comedia" only in the short title, "Comedia over TLS in SDP". RFC 4975 uses "comedia" only in this sentence: The mechanism was loosely based on the Connection-Oriented Media (COMEDIA) [26] work done by the MMUSIC working group. Reference [26] is RFC 4145. RFC 5567 uses "comedia" only in this sentence: [RFC4583] provides a way for SIP UAs to set up a BFCP connection towards the Floor Control Server and exploit floor control by means of a Connection-Oriented Media (COMEDIA) [RFC4145] negotiation. RFC 5631 uses "comedia" only in these two sentences: This problem could be solved through the use of Connection-Oriented Media (COMEDIA) [26], which specifies the "setup" SDP attribute to negotiate these roles. Assuming it agreed to such a session, it responds with a "setup" attribute, as per the COMEDIA specifications. Reference [26] is RFC 4145. RFC 6135 uses "comedia" in many places, and includes a definition of it in the abstract: [...] this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network RFC 6193 uses "comedia" only within the term "comedia-tls", which is defined as: [...] "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572] (hereafter referred to as comedia-tls) [...] RFC 6230 uses "comedia" to refer to RFC 4145, and to the SDP attribute "a=setup". The Connection-Oriented Media (COMEDIA) [RFC4145] specification for setting up and maintaining reliable connections is used as part of the negotiation mechanism (more detail available in later sections). If the Client initiating the SDP offer has a COMEDIA 'setup' attribute equal to active, [...] RFC 6787 uses "comedia" to refer to RFC 4572: When using TLS, the SDP "m=" line for the control stream MUST conform to Connection-Oriented Media (COMEDIA) over TLS [RFC4572], which specifies the usage of SDP for establishing a secure connection-oriented transport over TLS. RFC 6917 uses "comedia" in two places to refer to SDP support for connection-oriented media. ---------------------------------------------------------------------- Dale From rlb@ipv.sx Tue Apr 16 07:27:39 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2A021F9730 for ; Tue, 16 Apr 2013 07:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaK09VfsUzWv for ; Tue, 16 Apr 2013 07:27:38 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 242B921F9717 for ; Tue, 16 Apr 2013 07:27:38 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o17so414662oag.32 for ; Tue, 16 Apr 2013 07:27:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Q/hElcUm4M5a5aZSIUzGqdkvBl2wCZ1Muw/QsvlBTEY=; b=WvlzzGix8762jfFVbIQrCTVciHvI6UsUqSWUpAi285Q411QBNCYEfgDMqd8s9RQGnb wvmYI6jiijvBPZc60IB/wodiEJiM79jvkx2LBkIunyUXKIoO6Nbf2rPAyrlwTzwuwyAC gTw/vWgU9ZZKDUP6BNOU3qF6loVGxjVm0PkF/za/r3MP5oB2bnpofEEkHAloOcI6USbi JbTo3YKTzh4b/VvBNDZ0IJTfYTl0Zri+o2W/0/H8yCVmMfKjiAJ4x/b0tEP7EAn79pkM ZqJ280A0FrSQjXp0x06kOS9WVCRMXt0GSeoQFAuJ8Jafp60Kju/FmvfQL+LlLWVGS53J dQuw== MIME-Version: 1.0 X-Received: by 10.182.96.1 with SMTP id do1mr880851obb.17.1366122452754; Tue, 16 Apr 2013 07:27:32 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Tue, 16 Apr 2013 07:27:32 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <8BCECE3D-1D11-44DF-83CC-0B8D4462B6E4@standardstrack.com> References: <20130411214409.51DDEB1E003@rfc-editor.org> <8BCECE3D-1D11-44DF-83CC-0B8D4462B6E4@standardstrack.com> Date: Tue, 16 Apr 2013 10:27:32 -0400 Message-ID: From: Richard Barnes To: Eric Burger Content-Type: multipart/alternative; boundary=001a11c2fa02846a4704da7b2b20 X-Gm-Message-State: ALoCoQnkYiEUP8eSJcR9AjPOdckNIspllUYlU0oO+mVEuJfvvBbL8/KWKXScahbCZFAwBamWDxjX Cc: "mediactrl@ietf.org list mailing" Subject: Re: [MEDIACTRL] RFC 6917 on Media Resource Brokering X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 14:27:39 -0000 --001a11c2fa02846a4704da7b2b20 Content-Type: text/plain; charset=ISO-8859-1 I have asked the secretariat to make those changes. Good work, everyone! Thanks, --Richard On Sat, Apr 13, 2013 at 2:59 AM, Eric Burger wrote: > Richard - > Please make the following updates to our charter: > Mixer Control Protocol to IESG Done > Broker Protocol WGLC Done > Broker Protocol to IESG Done > Media Control Call Flows WGLC May 2013 > Media Control Call Flows to IESG July 2013 > > Thanks! > - Eric > > Begin forwarded message: > > *From: *rfc-editor@rfc-editor.org > *Subject: **[MEDIACTRL] RFC 6917 on Media Resource Brokering* > *Date: *April 11, 2013 5:44:09 PM EDT > *To: *ietf-announce@ietf.org, rfc-dist@rfc-editor.org > *Cc: *mediactrl@ietf.org, rfc-editor@rfc-editor.org > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6917 > > Title: Media Resource Brokering > Author: C. Boulton, L. Miniero, > G. Munson > Status: Standards Track > Stream: IETF > Date: April 2013 > Mailbox: chris@ns-technologies.com, > lorenzo@meetecho.com, > gamunson@gmail.com > Pages: 136 > Characters: 280399 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-mediactrl-mrb-19.txt > > URL: http://www.rfc-editor.org/rfc/rfc6917.txt > > The MediaCtrl working group in the IETF has proposed an architecture > for controlling media services. The Session Initiation Protocol > (SIP) is used as the signaling protocol that provides many inherent > capabilities for message routing. In addition to such signaling > properties, a need exists for intelligent, application-level media > service selection based on non-static signaling properties. This is > especially true when considered in conjunction with deployment > architectures that include 1:M and M:N combinations of Application > Servers and Media Servers. This document introduces a Media Resource > Broker (MRB) entity, which manages the availability of Media Servers > and the media resource demands of Application Servers. The document > includes potential deployment options for an MRB and appropriate > interfaces to Application Servers and Media Servers. > > This document is a product of the Media Server Control Working Group of > the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html > . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl > > > --001a11c2fa02846a4704da7b2b20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have asked the secretariat to make those changes. =A0

= Good work, everyone!

Thanks,
--Richard



On Sat, Apr 13, = 2013 at 2:59 AM, Eric Burger <eburger@standardstrack.com><= /span> wrote:
Richard = -
Please make the following updates to our charter:
Mixer Con= trol Protocol to IESG Done
Broker Protocol WGLC Don= e
Broker Protocol to IESG = Done
Media Control Call Flows WGLC May 2013
Media Control Call Flows to IESG = July 2013

Thanks!
- Eric

Begin forwarded message:

Subject: [MEDIACTRL] RFC 6917 on Medi= a Resource Brokering
Date: April 11, 2013 5:44:09 PM EDT

A new Request for Comments is = now available in online RFC libraries.


=A0=A0=A0=A0=A0=A0=A0RFC= 6917

=A0=A0=A0=A0=A0=A0=A0Title: =A0=A0=A0=A0=A0Media Resource Bro= kering
=A0=A0=A0=A0=A0=A0=A0Author: =A0=A0=A0=A0C. Boulton, L. Miniero= ,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0G. Munson
=A0= =A0=A0=A0=A0=A0=A0Status: =A0=A0=A0=A0Standards Track
=A0=A0=A0=A0=A0= =A0=A0Stream: =A0=A0=A0=A0IETF
=A0=A0=A0=A0=A0=A0=A0Date: =A0=A0=A0=A0= =A0=A0April 2013
=A0=A0=A0=A0=A0=A0=A0Mailbox: =A0=A0=A0chris@ns-technologies.com,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0lorenzo@meetecho.com,
=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0gamunson@gmail.com
=A0=A0=A0=A0= =A0=A0=A0Pages: =A0=A0=A0=A0=A0136
=A0=A0=A0=A0=A0=A0=A0Characters: 280399
=A0=A0=A0=A0=A0=A0=A0Updates/O= bsoletes/SeeAlso: =A0=A0None

=A0=A0=A0=A0=A0=A0=A0I-D Tag: =A0=A0= =A0draft-ietf-mediactrl-mrb-19.txt

=A0=A0=A0=A0=A0=A0=A0URL: =A0=A0= =A0=A0=A0=A0=A0http://www.rfc-editor.org/rfc/rfc6917.txt

The MediaCtrl working group in the IETF has proposed an architecturefor controlling media services. =A0The Session Initiation Protocol
(SIP= ) is used as the signaling protocol that provides many inherent
capabili= ties for message routing. =A0In addition to such signaling
properties, a need exists for intelligent, application-level media
servi= ce selection based on non-static signaling properties. =A0This is
especi= ally true when considered in conjunction with deployment
architectures t= hat include 1:M and M:N combinations of Application
Servers and Media Servers. =A0This document introduces a Media Resource
= Broker (MRB) entity, which manages the availability of Media Servers
and= the media resource demands of Application Servers. =A0The document
incl= udes potential deployment options for an MRB and appropriate
interfaces to Application Servers and Media Servers.

This document i= s a product of the Media Server Control Working Group of the IETF.

T= his is now a Proposed Standard.

STANDARDS TRACK: This document speci= fies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions=
for improvements. =A0Please refer to the current edition of the Interne= t
Official Protocol Standards (STD 1) for the standardization state and<= br> status of this protocol. =A0Distribution of this memo is unlimited.

= This announcement is sent to the IETF-Announce and rfc-dist lists.
To su= bscribe or unsubscribe, see
=A0http://www.ietf.org/mailman/listin= fo/ietf-announce
=A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<= br>
For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.ht= ml.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for= special distribution should be addressed to either the
author of the RF= C in question, or to rfc-editor@rfc-editor.org. =A0Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimit= ed distribution.


The RFC Editor Team
Association Management S= olutions, LLC


_______________________________________________ MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/m= ediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl<= br>


--001a11c2fa02846a4704da7b2b20-- From lorenzo@meetecho.com Wed Apr 17 08:24:13 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2F21E8089 for ; Wed, 17 Apr 2013 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD26+9F3o+g2 for ; Wed, 17 Apr 2013 08:24:10 -0700 (PDT) Received: from smtpdg11.aruba.it (smtpdg6.aruba.it [62.149.158.236]) by ietfa.amsl.com (Postfix) with ESMTP id 81F8A21F871C for ; Wed, 17 Apr 2013 08:24:08 -0700 (PDT) Received: from lminiero ([143.225.229.185]) by smtpcmd04.ad.aruba.it with bizsmtp id R3Q41l00z40f7Ln013Q4V9; Wed, 17 Apr 2013 17:24:05 +0200 Date: Wed, 17 Apr 2013 17:24:04 +0200 From: Lorenzo Miniero To: worley@ariadne.com (Dale R. Worley) Message-ID: <20130417172404.4b64082d@lminiero> In-Reply-To: <201304152148.r3FLmKaO2695748@shell01.TheWorld.com> References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> <201304152148.r3FLmKaO2695748@shell01.TheWorld.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:24:13 -0000 Hello Dale, thanks for the additional comments, I've added some replies inline prefixed by [LM2], L. Il giorno Mon, 15 Apr 2013 17:48:20 -0400 (EDT) worley@ariadne.com (Dale R. Worley) ha scritto: > > From: Eric Burger > > > > Are we done yet? > > Looking over the messages, I see that I should have responded to > Lorenzo's message of 26 Dec > (http://www.ietf.org/mail-archive/web/mediactrl/current/msg01781.html). > Of course, most of the items have already been resolved, but there are > a few that need more discussion. > > > > item 1) various > > > > > > The indentation of the header lines identifying various messages > > > is inconsistent. I can find the following lines in various > > > places: > > [...] > > > > [LM] You're right, the indentation often varies, and the logic > > behind this currently is according to whether or not the example > > fits the page. Instructions about this would be welcome! > > I think leaving it to the Editor may be the best, and the Editor will > have to worry about fitting the lines on the page anyway. The Editor > probably as style conventions about indenting. > [LM2] Ok. > > > item 2) various > > > > > > There are a lot of places where an arrow seems to go from a > > > network entity to itself, such as "create conf and its ID" below: > > > > > > AS MS > > > | | > > > | 1. CONTROL (create conference) | > > > |++++++++++++++++++++++++++++++++>>| > > > | |--+ create > > > | | | conf > > > and | 2. 200 OK (conferenceid=Y) |<-+ its ID > > > |<<++++++++++++++++++++++++++++++++| > > > > [LM] Yes, in that case the arrow was not meant as a network > > connection, but as a further step in the sequence diagram, that is > > what that CONTROL message triggers in the MS application logic. The > > same applies to all the examples where this happens. If you think > > the arrowless diagram is clearer to the reader we might remove > > them: the problem with this is that, without arrows, some diagrams > > might be harder to read, i.e., in terms of who does what in > > diagrams with several components interacting with each other. As an > > alternative, we might clarify what those arrows are and what they > > are not. What do you think about this? > > We might be able to choose a syntax that less resembles the > propagation of a message. Perhaps this: > > AS MS > | | > | 1. CONTROL (create conference) | > |++++++++++++++++++++++++++++++++>>| > | |-- create > | | conf and > | | its ID > | 2. 200 OK (conferenceid=Y) | > |<<++++++++++++++++++++++++++++++++| > > That makes it clear that the MS is performing an action, but it does > not look like generating a message. > [LM2] I've added some text in the "Conventions" section to clarify what those arrows mean: Besides, also note that a few diagrams present arrows that go from a network entity to itself. It's worth pointing out that such arrows do not represent any transaction message, but are rather meant as an indication to the reader that the involved network entity took a decision, within its application logic, according to the input it previously received. Do you think that may suffice? > > > item 7) section 4 > > > > > > This section starts with a paragraph over one page long. Could > > > it be broken into multiple paragraphs? > > > > [LM] Did you mean section 4.1? Section 4 starts with just a few > > lines. > > Yes, you are right, I meant section 4.1. > [LM2] Ok, I'll try and make it more readable. > > > item 9) section 4 figure 1 > > > [...] > > > - The states "'202' sent" and "'update' sent" have the same > > > outgoing transitions, so they should probably be merged. > > > > [LM] I'm not sure about this: 202 is only sent after the first > > CONTROL message to tell the AS it may take a while to process the > > request, after which you can either have further 202 messages > > should the processing take even more time, or one or more UPDATE > > messages related to that CONTROL request after that. They're two > > different messages in the protocol semantics. Nevertheless, it's > > also true that, according to RFC6230, a 202 is basically a > > pre-REPORT message... any feedback on this? > > The idea is that the MS is in the same state after sending the 202 as > it is after sending a subsequent update, because what it can do next > is the same, and so at least theoretically, the two states do not need > to be distinguished. > > My idea is that the diagram could be simplified to look like this: > > +------------------+ CONTROL/- +------------------+ API 202/202 > | Idle/'terminate' |------------>| CONTROL received |---------+ > +------------------+ +------------------+ | > ^ ^ ^ | | | > | | | API 200/200 | | | > | | +------------------+ | | > | 200/- | API Error/Error | | > | +----------------------------+ | > | | > | | > | API terminate/ v > +------------------+ REPORT terminate > +-------------------+ | 'terminate' sent > |<--------------------------| command executing | > +------------------+ +-------------------+ > ^ | | | API update/ > | | > REPORT update | | > | | > | | > 200/- | | > | v > +---------------+ > | 'update' sent | > +---------------+ > [LM2] That indeed looks much "cleaner" than what we have now. I'll have to check whether it actually addresses all the transitions we envisaged when first drawing the diagram that ended up in the draft. > > > item 9) section 4 figure 1 > > > [...] > > > - What happens if the API detects an error after 202 has been > > > sent? There is no "API Error" arc from "'202' sent"/"'update' > > > confirmed". > > > > [LM] Good point. The idea is that, once the MS sends a 202, the > > request has been correctly processed, and so is supposed to be fine > > as far as the protocol is concerned. I guess there could be > > circumstances when an errors occurs after that, e.g., in retrieving > > an audio file to be played to a UAC: in that case, the AS would be > > informed of the termination of the dialog/request in a REPORT > > terminate, including details on the issue which are Control Package > > specific. Do you think explaining this in the text may help readers? > > I think an explanation in the text would be helpful, although if the > reader has a thorough understanding of what information is carried in > REPORT terminate they would deduce the answer. Perhaps this > explanation would help those who are not completely familiar: > > The MS may send a 202 response after it determines that the request > request contains no errors that cannot be reported in a later > REPORT terminate request. After the MS sends a 202 response, any > error that it (or the API) finds in the request is reported in the > final REPORT terminate request. > [LM2] Thanks, I've added the explaination in place of the text I put there in the latest version, as yours is clearer. > > > item 12) section 5 > > > > > > The term "COMEDIA" is used, and a reference is given to RFC > > > 4145. But that RFC does not use the term "COMEDIA" at all. The > > > framework I-D also uses "COMEDIA" without explicitly defining > > > it. It would be helpful to insert here a definition of > > > "COMEDIA", which seems to be synonymous with "media of type > > > application/cfw". > > > > [LM] I thought COMEDIA actually came from RFC4145, standing for > > "connection-oriented media". Even the MSRP RFC refers to it that > > way. If that's incorrect or incomplete we'll fix this in the next > > version. > > I've searched through all the RFCs for the term "comedia". (The > results are summarized at the end of this message.) What seems to > have happened is that "comedia" has become an abbreviation for > "connection-oriented media" (i.e., TCP and TLS) and also for two RFCs > regarding support for connection-oriented media (RFC 4145 and RFC > 4572). > > The problem is that the term seems to be very common among a small > audience centered on Mediactrl, but only among that audience, and > people inside that audience do not take care to define it clearly for > the benefit of people outside that audience. For instance, RFC 5567 > is "An Architectural Framework for Media Server Control" and uses > "comedia" in "... exploit floor control by means of a > Connection-Oriented Media (COMEDIA) [RFC4145] negotiation." but > "comedia" is not listed in its section 2, "Terminology". > > I think this would be solved if "comedia" was listed in section 3, > "Terminology": > > COMEDIA: connection-oriented media (i.e., TCP and TLS). Also > used to signify the support in SDP for connection-oriented media, and > the RFCs that define that support (RFC 4145 and RFC 4572). > [LM2] Ok, I already expanded COMEDIA upon its first occurrence, but also specifying it in the terminology is probably better. > > > item 15) section 5.1 > > > > [...] > > > This confuses me: Either the list of packages in the SDP > > > offer/answer is significant or it is not. If it is not, why is > > > it provided? [...] > > > > [LM] That section refers to a draft Chris submitted to the MMUSIC WG > > some time ago: > > > > http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07 > > > > so any clarification about the purpose and constraints of such a > > mechanism should be addressed in the specification. Chris, do you > > think this behaviour could be clarified in the draft, in order to > > have it reflected in the Call Flows as a consequence? > > This looks complicated. It seems that > draft-boulton-mmusic-sdp-control-package-attribute has not been > adopted as a working group draft and has expired. If that is the > case, there will be no definition of the ctrl-package attribute, and > it shouldn't be used in the call-flows. > > But if that is fixed, it seems that we can copy some text from > draft-boulton-mmusic-sdp-control-package-attribute to clarify this > paragraph. I suggest splitting the paragraph, and amending the second > half like this: > > Note that the provided example also includes the indication, from > both the AS and the MS, of the supported control packages. This is > achieved by means of a series of 'ctrl-package' attributes as > specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. > In the example, the AS supports (or is only interested to) two > packages: IVR (Interactive Voice Response) and Mixer (Conferencing and > Bridging). The MS replies with the list of packages it supports, > adding a dummy example package to the list provided by the AS. > > It is worth noting that this exchange of information is only > advisory and neither endpoint is committing to support the packages > that are listed or to not supporting the packages that are not > listed. The actual negotiation of control packages is done > subsequently through the use of the framework SYNC transaction > within the control channel. Nonetheless, the use of 'ctrl-package' > attributes can be beneficial both from a resource allocation > perspective and it could also result in two clients identifying > they are not capable of successful control channel interactions. > This would lead to early abandonment of control channel setup (for > example, a client may choose to terminate the associated SIP dialog > and not attempt to make the connection). > [LM2] Ok, I'll do something like that should the issue with the expired document be fixed. > > > item 17) section 5.3 > > > > > > In the previous section it has been described how a timeout > > > value for the keep alive mechanism is negotiated. Specifically, > > > in the example the AS and the MS agreed on a value of 100 > > > seconds. > > > > > > In fact, that section does not describe how the value is > > > negotiated (since it is not clear what happens if the MS dislikes > > > the value proposed by the AS). However, this is correct: > > > > > > In example in the previous section, the AS and the MS agreed > > > on a value of 100 seconds. > > > > [LM] According to RFC6230, the 200 to the SYNC MUST have the same > > keep-alive value proposed in the original SYNC. Who sends the SYNC > > can change according to the COMEDIA negotiation. Specifically, "The > > previous steps ensure that the entity initiating the Control > > Channel connection is always the one specifying the keep-alive > > timeout period.". So, to answer your question, I guess that if a MS > > dislikes the value, it can just pick the active role and send a new > > SYNC with a new keep-alive value. > > OK, that was my mistake, as I was confusing how the MRB mechanism > works with the more complicated SIP timeout mechanism. But I think it > could be clarified by changing the two sentences to: > > In the previous section it has been described that the timeout > value for the keep-alive mechanism is set by the SYNC request. > Specifically, in the example the AS specified a value of 100 > seconds. > > In particular, the timeout value is not *negotiated* between the AS > and MS, it is simply specified by whichever endpoint takes the active > role. > [LM2] Ok. > > > item 22) section 6.1.2 > > > > > > The 202+REPORT(s) mechanism is used whenever the MS wants to > > > tell the AS that the requested operation might take some more > > > time than expected. > > > > [LM] Actually, the time is Control Package dependent. Different > > packages may have different timeouts. Quoting the framework, "A > > Control Package MUST explicitly define the circumstances under > > which the server sends 200 and 202 messages." > > Then the situation could be made clearer by writing: > > The 202+REPORT(s) mechanism is used whenever the MS wants to tell > the AS that the requested operation might take more time than > the limit specified in the definition of the Control Package. > [LM2] Ok. > > > item 23) section 6.2 figure 18 > > > > > > It might be useful to distinguish the four(?) SIP dialogs > > > involved. > > > > [LM] Do you mean as in different figures? or clearer text? > > I made a mistake there; I should have said "figure 17". > > The figure is a bit confusing, as there are either 3 or 4 SIP dialogs > involved, and the SIP messages are not marked to show which dialog > they are within. (Depending on how the AS functions, the SIP from > UAC2 to AS may or may not be within the same dialog as the SIP from > UAC1 to AS.) Someone familiar with AS/MS operation can guess which > messages are part of which dialogs, but it may be confusing for those > who are not familiar. It might not be important in this context, but > in RFCs that come out of the SIP WGs, in a situation like this, the > different SIP dialogs are distinguished by specifying Call-Id values. > In this case, figure 17 would look like this: > > UAC(1) UAC(2) AS > MS | | | | > | INVITE (offer A) | | > | Call-Id: A | | | > |---------------------------------->| | > | | 100 Trying | | > | | Call-Id: A | | > |<----------------------------------| | > | | INVITE (no offer) | | > | | Call-Id: B | | > | |<--------------------| | > | | 180 Ringing | | > | | Call-Id: B | | > | |-------------------->| | > | | 180 Ringing | | > | | Call-Id: A | | > |<----------------------------------| | > | | | INVITE (offer A) | > | | | Call-Id: C | > | | |-------------------------->| > | | | 200 OK (offer A') | > | | | Call-Id: C | > | | |<--------------------------| > | | | ACK | > | | | Call-Id: C | > | | |-------------------------->| > | | 200 OK (offer B) | | > | | Call-Id: B | | > | |-------------------->| | > | | | INVITE (offer B) | > | | | Call-Id: D | > | | |-------------------------->| > | | | 200 OK (offer B') | > | | | Call-Id: D | > | | |<--------------------------| > | | | ACK | > | | | Call-Id: D | > | | |-------------------------->| > | | ACK (offer B') | | > | | Call-Id: B | | > | |<--------------------| | > | | 200 OK (offer A') | | > | | Call-Id: A | | > |<----------------------------------| | > | ACK | | | > | Call-Id: A | | | > |---------------------------------->| | > | | | | > . . . . > . . . . > > (If the AS acts like a proxy between UAC1 and UAC2 rather than a > B2BUA, then "Call-Id: B" is replaced with "Call-Id: A" throughout.) > [LM2] Thanks for the hint, I've updated the diagram. > > > item 35) section 6.4 > > > > > > The discussion of mixing in the background music should be > > > contrasted with the mixing of the two recordings during playback > > > in section 6.2.3. Naively, it would seem that the same mixing > > > techniques could be used in both cases, but the two sections > > > implement mixing in entirely different ways. > > > > [LM] Are you talking of 6.4.2 (current time example)? If so, this > > was done on purpose, to exploit two different scenarios to showcase > > the use of two different techniques. You're right in saying that > > the same could be applied to both cases, nothing naive in this :-) > > OK, I see the point of the example. > > But I see another issue: It might help to add to section 3: > > VCR controls: runtime control of aspects of an audio playback like > speed and volume, via DTMF signals sent by the user, in a > manner that resembles the functions of a VCR (video cassette > recorder) controller. > [LM2] Ok. > > > item 36) section 6.4.3 > > > > > > An example contains XML elements that seem to be unnecessarily > > > complex: > > > > > > > > > > > > * > > > > > > > > > > > > > > > As far as I can tell from the SRGS specification, functions > > > more-or-less as a type of parenthesis, and is needed only when > > > (1) a "weight" or "repeat" attribute needs to be applied to the > > > group, (2) delimiting one alternative of a element, or > > > (3) constructing the "null" regular expression (that consumes no > > > input and always matches). Thus, these examples can be > > > simplified to: > > > > > > > > > * > > > > > > > > > > > > Then again, if the example is taken from a real interaction, > > > perhaps it is best to leave it as it really happened. > > > > [LM] I'm not an expert of SRGS, so I'm not sure about this. This is > > how we implemented it in our Media Server, and it works this way, > > but it would be nice to hear from other implementers to see if they > > usually realize similar scenarios in a different way! > > Yes, let us ask implementers what they think is clearer. > > > > item 38) section 6.4.3 > > > > > > This section leads to a question about the semantics of the > > > operation: Clearly, initially > > > the stream is output at the same volume as the input media. But > > > when "" is applied, does > > > that cause the stream's output volume to be set to +1 dB > > > *relative to the input media* or to +1 dB *relative to the > > > previous volume setting*? > > > > > > E.g., if I apply that operation twice, does the second application > > > leave the amplification at +1 dB or raise it to +2 dB? > > > > > > The examples in section 6.4.3 suggest the second interpretation. > > > > > > The text in draft-ietf-mediactrl-mixer-control-package-14 is not > > > clear on this point: "setgain" is only discussed in section > > > 4.2.2.5.1, and it says "use the value of the "value" attribute as > > > a specific gain measured in dB to apply". That would be most > > > likely to mean "as a specific gain measured in dB to apply to the > > > input", which suggests the first interpretation. > > > > > > In any case, the semantics of this need to be clarified and the > > > example adjusted accordingly. > > > > [LM] If I recall correctly, when we first implemented this we > > discussed it with the IVR authors during a meeting. If I'm not > > wrong the conclusion was that setgain *sets* the gain, and does not > > modify the previous value. I don't have the MS code in front of me > > right now, though, I'll have to double check how we implemented > > this and let you know. > > > > IVR authors, any insight on this from a specification point of view? > > Now that I think about it more, I think the usual terminology is that > the gain is seen as the difference between the input and the output, > and "setting" it means fixing the gain at a specific number. However, > in many usages, a number prefixed by "+" or "-" is used to mean an > increment/decrement relative to the previous value. What misleads me > is that the setgain operations are shown as implementations of the *1 > and *9 requests, which are *incremental*. The possibility of > misunderstanding could be removed by adding a comment. > [LM2] Good point, especially as I checked our implementation and it works how I thought, that is, by setting the gain instead of incrementing/decrementing it. I'll clarify that, to map it to an incremental operation, it's up to the AS to remember the current status and modify it accordingly when needed. > (Also, I think that each bullet point should be shown as sentences, > that is, starting with a capital letter and ending with a period, > rather than many clauses separated by ";". Here, I have left the > paragraphs un-filled to make my change clearer; you probably want to > fill the entire bullet point.) > > o The AS ACKs the event (B2), and in its business logic > understands that the code '*1' means that the UAC wants its own > volume to be lowered in the conference mix. The AS is able to > associate the event with the right UAC by referring to the attached > dialogid (01d1b38). It then acts accordingly, by sending a > (C1) which does exactly this: the provided > child element instructs the MS to modify the volume of the > UAC-->conference audio flow (setgain=-5dB sendonly). > Notice that the "setgain" value is the absolute volume level; if > the user's request is to lower the volume level, the AS must > remember the previously set volume level and from it calculate > the new volume level. > Notice how the request also > includes directives upon the inverse direction. This verbose > approach is needed, since otherwise the MS would not only change > the volume in the requested direction, but also disable the > media flow in the other direction; having a proper addressing > the UAC<--conf media flow as well ensures that this doesn't > happen. > > Since we have clarified the situation with the first "setgain", there > is no need to repeat the clarification for the second "setgain". > [LM2] Ok. > > > item 41) section 7.1, section 7.2, section 7.2.1 > > > [...] > > > Generally, "AS" and "MS" are used as the plurals of "AS" and > > > "MS", but in these instances, "ASs" and "MSs" are used. > > > > [LM] [...] Besides, ASs sounds really bad... :-) > > Ah, yes, I overlooked that. :-) > > > > item 46) section 7.2.2.1, section 7.2.2.2 > > > > > > Please note that, to ease the reading of the protocol > > > contents, a simple '=_Part' is used whenever a boundary for a > > > 'multipart/mixed' payload is provided, instead of the actual > > > boundary that would be inserted in the SIP messages. > > > > > > This seems like a poor strategy, as the resulting figures are not > > > strictly correct. Perhaps use "Part" as the boundary value, which > > > would result in figures that look like the following, which > > > strictly correct and are just as easy to read: > > > > > > [..] > > > Content-Type: multipart/mixed;boundary="Part" > > > > > > --Part > > > Content-Type: application/sdp > > > > > > v=0 > > > o=- 2890844526 2890842807 IN IP4 as.example.com > > > [...] > > > > > > --Part > > > Content-Type: application/mrb-consumer+xml > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:mrb-consumer"> > > > [...] > > > > > > > > > --Part-- > > > > [LM] I think we did it this way after a comment received on the > > list: Chris and I did the same for the examples in the MRB draft, > > for instance. If you think it might improve the readability of the > > document we'll change this. > > I can't find the message that you mention, although the change is > clear between draft-ietf-mediactrl-mrb-03 and -04. For example: > > 1. AS -> MRB (INVITE multipart/mixed) > ------------------------------------- > [..] > Content-Type: multipart/mixed; \ > boundary="----=_Part_0_19138361.1261662356915" > > ------=_Part_0_19138361.1261662356915 > Content-Type: application/sdp > > v=0 > > becomes > > 1. AS -> MRB (INVITE multipart/mixed) > ------------------------------------- > [..] > Content-Type: multipart/mixed;boundary="=_Part" > > =_Part > Content-Type: application/sdp > > v=0 > > But you could make the example both easy to read and formally correct > by just using "Part" as the boundary value (because no body line > starts with "--Part"): > > 1. AS -> MRB (INVITE multipart/mixed) > ------------------------------------- > [..] > Content-Type: multipart/mixed;boundary="Part" > > --Part > Content-Type: application/sdp > > v=0 > [LM2] Ok, I'll fix the boundary in all the examples. > > > item 51) section 7.3.1 > > > > > > We might want to mention that in this scenario, the AS obtains > > > assignment of an MS *before* any UAC makes a request, in order to > > > have facilities to satisfy future SIP requests. That is probably > > > how AS's operate in practice, but a naive reader might expect > > > that the AS will make the consumer request only after the AS > > > receives a demand for its services. > > > > [LM] Actually both Fig.53 and 54 show the AS creating a control > > channel before receiving an INVITE from the UAC. Or was your point > > about a different aspect? > > I think my point was that you might want to call out in the text that > the AS creates a control channel to a chosen MS *before* it has any > requests to service. > [LM2] Ok, I'll clarify this at the beginning of the section. > > > item 53) section 7.3.2 > > > > > > While apparently not a problem, this raises an issue when the > > > same unaware AS has several sessions with different MS: the AS > > > would only see one "virtual" MS (the MRB) and so it would relay > > > all calls there, making it hard for the MRB to understand where > > > these media dialogs should belong: specifically, whether the UAC > > > calling belongs to the AS application logic leading to MS1 or > > > MS2, or wherever else. > > > > > > This seems to be a deficiency in the CFW protocol: If the AS > > > establishes a CFW channel with the MS (via a SIP URI to an MRB), > > > and then later the AS wants to addresses a SIP INVITE to the MS, > > > it has no choice but to use the same SIP URI (which routes to the > > > MRB). This makes it impossible for the MRB to associate the SIP > > > INVITE with the CFW connection, and thus it is difficult for the > > > MRB to route the INVITE to the same MS. > > > > > > What seems to be needed is for either the COMEDIA response > > > (application/cfw) or CFW connection to provide a SIP URI that is > > > the "real" SIP URI of the far-end of the CFW channel. > > > > > > Actually, this seems to be a problem even if an AS is addressing > > > an MS URI, but the URI resolves to a redundant set of MSs: There > > > seems to be no way to ensure that when a CFW channel is > > > established that a subsequent SIP INVITE can be sent to the same > > > MS. This issue seems to be discussed in RFC 6230 section 3, but > > > I can't find any solution there. > > > > [LM] The way it works now is that, for a specific MS, the same SIP > > URI is used for both negotiating a control channel and attaching > > media dialogs, yes. A way to overcome this may having the MS > > redirect media dialogs to a different SIP URI when it receives them > > (that is, treat control and media dialogs differently) but I > > realize how this sounds like an implementation hack rather than a > > real solution. > > If an AS is contacting an MS directly, then there is not much of a > problem with the AS using the same URI for negotiating CFW and for > establishing SIP dialogs. But if the AS is contacting an MRB and the > MRB is contacting an MS, when the MRB receives the SIP INVITE, it must > be able to determine that the AS wants to have the INVITE forwarded to > the same MS to which the MRB forwarded the CFW previously. How does > the MRB determine that the AS intends the INVITE to go to the same > destination as a particular CFW channel? > [LM2] If I recall correctly, we discussed this a few meetings ago, in Anaheim, when I presented the MRB draft. The discussion eventually resulted in sections 5.3 and 6 of the new MRB RFC (http://tools.ietf.org/html/rfc6917). This is a link to the minutes: http://www.ietf.org/proceedings/77/minutes/mediactrl.htm Considering it's the MRB that sends back the addresses to use to reach the MS, if it wants to be in the signalling path, it can return different SIP URIs, all managed by the MRB, that internally map to the actual MS endpoints. If I'm not wrong, you also suggested using something like SIP URI tags to make this work, but I can't find a match in the minutes. Anyway, the issue is broader when you have the MRB acting as a B2BUA rather than a proxy, as in that case you risk ending up messing the connectionid identifiers that are used to address media connections. > > > item 55) section 8 > > > > > > The detailed discussion of how the MS enforces security against > > > the ASs is helpful, but it does not mention how the MS discerns > > > which requests come from AS1 and which come from AS2. > > I did not see a response to this issue. > [LM2] The AS and MS do a SYNC when they first set up the control channel, and since it involves info coming from the SDP that allows a MS to know that TCP connection comes from an AS in particular. Do you think this needs to be clarified in the document? I'll add some brief text to make this clearer. Thanks! Lorenzo > ---------------------------------------------------------------------- > > Summary of uses of "comedia" in published RFCs > > RFC 4145 does not contain the term "comedia" at all, although its > short title is "Connection-Oriented Media". > > RFC 4571 uses "comedia" only as the name of a Normative Reference to > RFC 4145. > > RFC 4572 uses "comedia" only in the short title, "Comedia over TLS in > SDP". > > RFC 4975 uses "comedia" only in this sentence: > > The mechanism was loosely based on the Connection-Oriented Media > (COMEDIA) [26] work done by the MMUSIC working group. > > Reference [26] is RFC 4145. > > RFC 5567 uses "comedia" only in this sentence: > > [RFC4583] provides a way for SIP UAs to set up a BFCP connection > towards the Floor Control Server and exploit floor control by means > of a Connection-Oriented Media (COMEDIA) [RFC4145] negotiation. > > RFC 5631 uses "comedia" only in these two sentences: > > This problem could be solved through the use of Connection-Oriented > Media (COMEDIA) [26], which specifies the "setup" SDP attribute to > negotiate these roles. > > Assuming it agreed to such a session, it responds with a "setup" > attribute, as per the COMEDIA specifications. > > Reference [26] is RFC 4145. > > RFC 6135 uses "comedia" in many places, and includes a definition of > it in the abstract: > > [...] this model uses the connection-oriented media (COMEDIA) > mechanism in order to create the MSRP transport connection. The > model allows MSRP UAs behind Network > > RFC 6193 uses "comedia" only within the term "comedia-tls", which is > defined as: > > [...] "Connection-Oriented Media Transport over the Transport > Layer Security (TLS) Protocol in the Session Description Protocol > (SDP)" [RFC4572] (hereafter referred to as comedia-tls) [...] > > RFC 6230 uses "comedia" to refer to RFC 4145, and to the SDP attribute > "a=setup". > > The Connection-Oriented Media (COMEDIA) [RFC4145] specification for > setting up and maintaining reliable connections is used as part of > the negotiation mechanism (more detail available in later > sections). > > If the Client initiating the SDP offer has a COMEDIA 'setup' > attribute equal to active, [...] > > RFC 6787 uses "comedia" to refer to RFC 4572: > > When using TLS, the SDP "m=" line for the control stream MUST > conform to Connection-Oriented Media (COMEDIA) over TLS [RFC4572], > which specifies the usage of SDP for establishing a secure > connection-oriented transport over TLS. > > RFC 6917 uses "comedia" in two places to refer to SDP support for > connection-oriented media. > > ---------------------------------------------------------------------- > > Dale > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl From internet-drafts@ietf.org Mon Apr 22 04:30:36 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B3721F8E6E; Mon, 22 Apr 2013 04:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KRJErb-9p5X; Mon, 22 Apr 2013 04:30:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAECA21F8E2C; Mon, 22 Apr 2013 04:30:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130422113035.30401.14168.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 04:30:35 -0700 Cc: mediactrl@ietf.org Subject: [MEDIACTRL] I-D Action: draft-ietf-mediactrl-call-flows-12.txt X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 11:30:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Media Server Control Working Group of the= IETF. Title : Media Control Channel Framework (CFW) Call Flow Examples Author(s) : Alessandro Amirante Tobia Castaldi Lorenzo Miniero Simon Pietro Romano Filename : draft-ietf-mediactrl-call-flows-12.txt Pages : 173 Date : 2013-04-22 Abstract: This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mediactrl-call-flows-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mediactrl-call-flows-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@meetecho.com Tue Apr 23 03:42:44 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5F21F964E for ; Tue, 23 Apr 2013 03:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQAXI9s6sMdu for ; Tue, 23 Apr 2013 03:42:42 -0700 (PDT) Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id F059E21F964D for ; Tue, 23 Apr 2013 03:42:40 -0700 (PDT) Received: from localhost.localdomain ([143.225.229.188]) by smtpcmd01.ad.aruba.it with bizsmtp id TNid1l00744Y8Mb01Nid41; Tue, 23 Apr 2013 12:42:38 +0200 Date: Tue, 23 Apr 2013 12:42:36 +0200 From: Lorenzo Miniero To: worley@ariadne.com (Dale R. Worley) Message-ID: <20130423124236.3aabf5d8@meetecho.com> In-Reply-To: <20130417172404.4b64082d@lminiero> References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> <201304152148.r3FLmKaO2695748@shell01.TheWorld.com> <20130417172404.4b64082d@lminiero> Organization: Meetecho X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mediactrl@ietf.org Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10 X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 10:42:44 -0000 Hello Dale and all, I published a revised version of the document, which incorporates all the suggestions and fixes by Dale: the only thing I left out was the revised state diagram, as I felt that, although the one by Dale was cleaner, the one we had made it clearer that the fact that some messages are actually sent, and there isn't only an internal API transition within the node (e.g., "202 sent"). Lorenzo Il giorno Wed, 17 Apr 2013 17:24:04 +0200 Lorenzo Miniero ha scritto: > Hello Dale, > > thanks for the additional comments, I've added some replies inline > prefixed by [LM2], > > L. > > > Il giorno Mon, 15 Apr 2013 17:48:20 -0400 (EDT) > worley@ariadne.com (Dale R. Worley) ha scritto: > > > > From: Eric Burger > > > > > > Are we done yet? > > > > Looking over the messages, I see that I should have responded to > > Lorenzo's message of 26 Dec > > (http://www.ietf.org/mail-archive/web/mediactrl/current/msg01781.html). > > Of course, most of the items have already been resolved, but there > > are a few that need more discussion. > > > > > > item 1) various > > > > > > > > The indentation of the header lines identifying various messages > > > > is inconsistent. I can find the following lines in various > > > > places: > > > [...] > > > > > > [LM] You're right, the indentation often varies, and the logic > > > behind this currently is according to whether or not the example > > > fits the page. Instructions about this would be welcome! > > > > I think leaving it to the Editor may be the best, and the Editor > > will have to worry about fitting the lines on the page anyway. The > > Editor probably as style conventions about indenting. > > > > > [LM2] Ok. > > > > > > item 2) various > > > > > > > > There are a lot of places where an arrow seems to go from a > > > > network entity to itself, such as "create conf and its ID" > > > > below: > > > > > > > > AS MS > > > > | | > > > > | 1. CONTROL (create conference) | > > > > |++++++++++++++++++++++++++++++++>>| > > > > | |--+ > > > > create | | | conf > > > > and | 2. 200 OK (conferenceid=Y) |<-+ its ID > > > > |<<++++++++++++++++++++++++++++++++| > > > > > > [LM] Yes, in that case the arrow was not meant as a network > > > connection, but as a further step in the sequence diagram, that is > > > what that CONTROL message triggers in the MS application logic. > > > The same applies to all the examples where this happens. If you > > > think the arrowless diagram is clearer to the reader we might > > > remove them: the problem with this is that, without arrows, some > > > diagrams might be harder to read, i.e., in terms of who does what > > > in diagrams with several components interacting with each other. > > > As an alternative, we might clarify what those arrows are and > > > what they are not. What do you think about this? > > > > We might be able to choose a syntax that less resembles the > > propagation of a message. Perhaps this: > > > > AS MS > > | | > > | 1. CONTROL (create conference) | > > |++++++++++++++++++++++++++++++++>>| > > | |-- create > > | | conf and > > | | its ID > > | 2. 200 OK (conferenceid=Y) | > > |<<++++++++++++++++++++++++++++++++| > > > > That makes it clear that the MS is performing an action, but it does > > not look like generating a message. > > > > > [LM2] I've added some text in the "Conventions" section to clarify > what those arrows mean: > > Besides, also note that a few diagrams present arrows that go > from a network entity to itself. It's worth pointing out that > such arrows do not represent any transaction message, but are > rather meant as an indication to the reader that the involved > network entity took a decision, within its application logic, > according to the input it previously received. > > Do you think that may suffice? > > > > > > item 7) section 4 > > > > > > > > This section starts with a paragraph over one page long. Could > > > > it be broken into multiple paragraphs? > > > > > > [LM] Did you mean section 4.1? Section 4 starts with just a few > > > lines. > > > > Yes, you are right, I meant section 4.1. > > > > > [LM2] Ok, I'll try and make it more readable. > > > > > > item 9) section 4 figure 1 > > > > [...] > > > > - The states "'202' sent" and "'update' sent" have the same > > > > outgoing transitions, so they should probably be merged. > > > > > > [LM] I'm not sure about this: 202 is only sent after the first > > > CONTROL message to tell the AS it may take a while to process the > > > request, after which you can either have further 202 messages > > > should the processing take even more time, or one or more UPDATE > > > messages related to that CONTROL request after that. They're two > > > different messages in the protocol semantics. Nevertheless, it's > > > also true that, according to RFC6230, a 202 is basically a > > > pre-REPORT message... any feedback on this? > > > > The idea is that the MS is in the same state after sending the 202 > > as it is after sending a subsequent update, because what it can do > > next is the same, and so at least theoretically, the two states do > > not need to be distinguished. > > > > My idea is that the diagram could be simplified to look like this: > > > > +------------------+ CONTROL/- +------------------+ API 202/202 > > | Idle/'terminate' |------------>| CONTROL received |---------+ > > +------------------+ +------------------+ | > > ^ ^ ^ | | | > > | | | API 200/200 | | | > > | | +------------------+ | | > > | 200/- | API Error/Error | | > > | +----------------------------+ | > > | | > > | | > > | API terminate/ v > > +------------------+ REPORT terminate > > +-------------------+ | 'terminate' sent > > |<--------------------------| command executing | > > +------------------+ +-------------------+ > > ^ | | | API update/ > > | | > > REPORT update | | > > | | > > | | > > 200/- | | > > | v > > +---------------+ > > | 'update' > > sent | +---------------+ > > > > > [LM2] That indeed looks much "cleaner" than what we have now. I'll > have to check whether it actually addresses all the transitions we > envisaged when first drawing the diagram that ended up in the draft. > > > > > > item 9) section 4 figure 1 > > > > [...] > > > > - What happens if the API detects an error after 202 has been > > > > sent? There is no "API Error" arc from "'202' sent"/"'update' > > > > confirmed". > > > > > > [LM] Good point. The idea is that, once the MS sends a 202, the > > > request has been correctly processed, and so is supposed to be > > > fine as far as the protocol is concerned. I guess there could be > > > circumstances when an errors occurs after that, e.g., in > > > retrieving an audio file to be played to a UAC: in that case, the > > > AS would be informed of the termination of the dialog/request in > > > a REPORT terminate, including details on the issue which are > > > Control Package specific. Do you think explaining this in the > > > text may help readers? > > > > I think an explanation in the text would be helpful, although if the > > reader has a thorough understanding of what information is carried > > in REPORT terminate they would deduce the answer. Perhaps this > > explanation would help those who are not completely familiar: > > > > The MS may send a 202 response after it determines that the > > request request contains no errors that cannot be reported in a > > later REPORT terminate request. After the MS sends a 202 response, > > any error that it (or the API) finds in the request is reported in > > the final REPORT terminate request. > > > > > [LM2] Thanks, I've added the explaination in place of the text I put > there in the latest version, as yours is clearer. > > > > > > item 12) section 5 > > > > > > > > The term "COMEDIA" is used, and a reference is given to RFC > > > > 4145. But that RFC does not use the term "COMEDIA" at all. The > > > > framework I-D also uses "COMEDIA" without explicitly defining > > > > it. It would be helpful to insert here a definition of > > > > "COMEDIA", which seems to be synonymous with "media of type > > > > application/cfw". > > > > > > [LM] I thought COMEDIA actually came from RFC4145, standing for > > > "connection-oriented media". Even the MSRP RFC refers to it that > > > way. If that's incorrect or incomplete we'll fix this in the next > > > version. > > > > I've searched through all the RFCs for the term "comedia". (The > > results are summarized at the end of this message.) What seems to > > have happened is that "comedia" has become an abbreviation for > > "connection-oriented media" (i.e., TCP and TLS) and also for two > > RFCs regarding support for connection-oriented media (RFC 4145 and > > RFC 4572). > > > > The problem is that the term seems to be very common among a small > > audience centered on Mediactrl, but only among that audience, and > > people inside that audience do not take care to define it clearly > > for the benefit of people outside that audience. For instance, RFC > > 5567 is "An Architectural Framework for Media Server Control" and > > uses "comedia" in "... exploit floor control by means of a > > Connection-Oriented Media (COMEDIA) [RFC4145] negotiation." but > > "comedia" is not listed in its section 2, "Terminology". > > > > I think this would be solved if "comedia" was listed in section 3, > > "Terminology": > > > > COMEDIA: connection-oriented media (i.e., TCP and TLS). Also > > used to signify the support in SDP for connection-oriented media, > > and the RFCs that define that support (RFC 4145 and RFC 4572). > > > > > [LM2] Ok, I already expanded COMEDIA upon its first occurrence, but > also specifying it in the terminology is probably better. > > > > > > item 15) section 5.1 > > > > > [...] > > > > This confuses me: Either the list of packages in the SDP > > > > offer/answer is significant or it is not. If it is not, why is > > > > it provided? [...] > > > > > > [LM] That section refers to a draft Chris submitted to the MMUSIC > > > WG some time ago: > > > > > > http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07 > > > > > > so any clarification about the purpose and constraints of such a > > > mechanism should be addressed in the specification. Chris, do you > > > think this behaviour could be clarified in the draft, in order to > > > have it reflected in the Call Flows as a consequence? > > > > This looks complicated. It seems that > > draft-boulton-mmusic-sdp-control-package-attribute has not been > > adopted as a working group draft and has expired. If that is the > > case, there will be no definition of the ctrl-package attribute, and > > it shouldn't be used in the call-flows. > > > > But if that is fixed, it seems that we can copy some text from > > draft-boulton-mmusic-sdp-control-package-attribute to clarify this > > paragraph. I suggest splitting the paragraph, and amending the > > second half like this: > > > > Note that the provided example also includes the indication, from > > both the AS and the MS, of the supported control packages. This > > is achieved by means of a series of 'ctrl-package' attributes as > > specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. > > In the example, the AS supports (or is only interested to) two > > packages: IVR (Interactive Voice Response) and Mixer (Conferencing > > and Bridging). The MS replies with the list of packages it > > supports, adding a dummy example package to the list provided by > > the AS. > > > > It is worth noting that this exchange of information is only > > advisory and neither endpoint is committing to support the > > packages that are listed or to not supporting the packages that are > > not listed. The actual negotiation of control packages is done > > subsequently through the use of the framework SYNC transaction > > within the control channel. Nonetheless, the use of > > 'ctrl-package' attributes can be beneficial both from a resource > > allocation perspective and it could also result in two clients > > identifying they are not capable of successful control channel > > interactions. This would lead to early abandonment of control > > channel setup (for example, a client may choose to terminate the > > associated SIP dialog and not attempt to make the connection). > > > > > [LM2] Ok, I'll do something like that should the issue with the > expired document be fixed. > > > > > > item 17) section 5.3 > > > > > > > > In the previous section it has been described how a timeout > > > > value for the keep alive mechanism is negotiated. Specifically, > > > > in the example the AS and the MS agreed on a value of 100 > > > > seconds. > > > > > > > > In fact, that section does not describe how the value is > > > > negotiated (since it is not clear what happens if the MS > > > > dislikes the value proposed by the AS). However, this is > > > > correct: > > > > > > > > In example in the previous section, the AS and the MS agreed > > > > on a value of 100 seconds. > > > > > > [LM] According to RFC6230, the 200 to the SYNC MUST have the same > > > keep-alive value proposed in the original SYNC. Who sends the SYNC > > > can change according to the COMEDIA negotiation. Specifically, > > > "The previous steps ensure that the entity initiating the Control > > > Channel connection is always the one specifying the keep-alive > > > timeout period.". So, to answer your question, I guess that if a > > > MS dislikes the value, it can just pick the active role and send > > > a new SYNC with a new keep-alive value. > > > > OK, that was my mistake, as I was confusing how the MRB mechanism > > works with the more complicated SIP timeout mechanism. But I think > > it could be clarified by changing the two sentences to: > > > > In the previous section it has been described that the timeout > > value for the keep-alive mechanism is set by the SYNC request. > > Specifically, in the example the AS specified a value of 100 > > seconds. > > > > In particular, the timeout value is not *negotiated* between the AS > > and MS, it is simply specified by whichever endpoint takes the > > active role. > > > > > [LM2] Ok. > > > > > > item 22) section 6.1.2 > > > > > > > > The 202+REPORT(s) mechanism is used whenever the MS wants to > > > > tell the AS that the requested operation might take some more > > > > time than expected. > > > > > > [LM] Actually, the time is Control Package dependent. Different > > > packages may have different timeouts. Quoting the framework, "A > > > Control Package MUST explicitly define the circumstances under > > > which the server sends 200 and 202 messages." > > > > Then the situation could be made clearer by writing: > > > > The 202+REPORT(s) mechanism is used whenever the MS wants to > > tell the AS that the requested operation might take more time than > > the limit specified in the definition of the Control Package. > > > > > [LM2] Ok. > > > > > > item 23) section 6.2 figure 18 > > > > > > > > It might be useful to distinguish the four(?) SIP dialogs > > > > involved. > > > > > > [LM] Do you mean as in different figures? or clearer text? > > > > I made a mistake there; I should have said "figure 17". > > > > The figure is a bit confusing, as there are either 3 or 4 SIP > > dialogs involved, and the SIP messages are not marked to show which > > dialog they are within. (Depending on how the AS functions, the > > SIP from UAC2 to AS may or may not be within the same dialog as the > > SIP from UAC1 to AS.) Someone familiar with AS/MS operation can > > guess which messages are part of which dialogs, but it may be > > confusing for those who are not familiar. It might not be > > important in this context, but in RFCs that come out of the SIP > > WGs, in a situation like this, the different SIP dialogs are > > distinguished by specifying Call-Id values. In this case, figure 17 > > would look like this: > > > > UAC(1) UAC(2) AS > > MS | | | | > > | INVITE (offer A) > > | | | Call-Id: A | > > | | > > |---------------------------------->| | > > | | 100 Trying | | > > | | Call-Id: A | | > > |<----------------------------------| | > > | | INVITE (no offer) | | > > | | Call-Id: B | | > > | |<--------------------| | > > | | 180 Ringing | | > > | | Call-Id: B | | > > | |-------------------->| | > > | | 180 Ringing | | > > | | Call-Id: A | | > > |<----------------------------------| | > > | | | INVITE (offer A) | > > | | | Call-Id: C | > > | | |-------------------------->| > > | | | 200 OK (offer A') | > > | | | Call-Id: C | > > | | |<--------------------------| > > | | | ACK | > > | | | Call-Id: C | > > | | |-------------------------->| > > | | 200 OK (offer B) | | > > | | Call-Id: B | | > > | |-------------------->| | > > | | | INVITE (offer B) | > > | | | Call-Id: D | > > | | |-------------------------->| > > | | | 200 OK (offer B') | > > | | | Call-Id: D | > > | | |<--------------------------| > > | | | ACK | > > | | | Call-Id: D | > > | | |-------------------------->| > > | | ACK (offer B') | | > > | | Call-Id: B | | > > | |<--------------------| | > > | | 200 OK (offer A') | | > > | | Call-Id: A | | > > |<----------------------------------| | | > > ACK | | | | > > Call-Id: A | | | > > |---------------------------------->| | > > | | | > > | . . . . . . . . > > > > (If the AS acts like a proxy between UAC1 and UAC2 rather than a > > B2BUA, then "Call-Id: B" is replaced with "Call-Id: A" throughout.) > > > > > [LM2] Thanks for the hint, I've updated the diagram. > > > > > > item 35) section 6.4 > > > > > > > > The discussion of mixing in the background music should be > > > > contrasted with the mixing of the two recordings during playback > > > > in section 6.2.3. Naively, it would seem that the same mixing > > > > techniques could be used in both cases, but the two sections > > > > implement mixing in entirely different ways. > > > > > > [LM] Are you talking of 6.4.2 (current time example)? If so, this > > > was done on purpose, to exploit two different scenarios to > > > showcase the use of two different techniques. You're right in > > > saying that the same could be applied to both cases, nothing > > > naive in this :-) > > > > OK, I see the point of the example. > > > > But I see another issue: It might help to add to section 3: > > > > VCR controls: runtime control of aspects of an audio playback > > like speed and volume, via DTMF signals sent by the user, in a > > manner that resembles the functions of a VCR (video cassette > > recorder) controller. > > > > > [LM2] Ok. > > > > > > item 36) section 6.4.3 > > > > > > > > An example contains XML elements that seem to be unnecessarily > > > > complex: > > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > As far as I can tell from the SRGS specification, > > > > functions more-or-less as a type of parenthesis, and is needed > > > > only when (1) a "weight" or "repeat" attribute needs to be > > > > applied to the group, (2) delimiting one alternative of a > > > > element, or (3) constructing the "null" regular > > > > expression (that consumes no input and always matches). Thus, > > > > these examples can be simplified to: > > > > > > > > > > > > * > > > > > > > > > > > > > > > > Then again, if the example is taken from a real interaction, > > > > perhaps it is best to leave it as it really happened. > > > > > > [LM] I'm not an expert of SRGS, so I'm not sure about this. This > > > is how we implemented it in our Media Server, and it works this > > > way, but it would be nice to hear from other implementers to see > > > if they usually realize similar scenarios in a different way! > > > > Yes, let us ask implementers what they think is clearer. > > > > > > item 38) section 6.4.3 > > > > > > > > This section leads to a question about the semantics of the > > > > operation: Clearly, > > > > initially the stream is output at the same volume as the input > > > > media. But when "" is > > > > applied, does that cause the stream's output volume to be set > > > > to +1 dB *relative to the input media* or to +1 dB *relative to > > > > the previous volume setting*? > > > > > > > > E.g., if I apply that operation twice, does the second > > > > application leave the amplification at +1 dB or raise it to +2 > > > > dB? > > > > > > > > The examples in section 6.4.3 suggest the second interpretation. > > > > > > > > The text in draft-ietf-mediactrl-mixer-control-package-14 is not > > > > clear on this point: "setgain" is only discussed in section > > > > 4.2.2.5.1, and it says "use the value of the "value" attribute > > > > as a specific gain measured in dB to apply". That would be most > > > > likely to mean "as a specific gain measured in dB to apply to > > > > the input", which suggests the first interpretation. > > > > > > > > In any case, the semantics of this need to be clarified and the > > > > example adjusted accordingly. > > > > > > [LM] If I recall correctly, when we first implemented this we > > > discussed it with the IVR authors during a meeting. If I'm not > > > wrong the conclusion was that setgain *sets* the gain, and does > > > not modify the previous value. I don't have the MS code in front > > > of me right now, though, I'll have to double check how we > > > implemented this and let you know. > > > > > > IVR authors, any insight on this from a specification point of > > > view? > > > > Now that I think about it more, I think the usual terminology is > > that the gain is seen as the difference between the input and the > > output, and "setting" it means fixing the gain at a specific > > number. However, in many usages, a number prefixed by "+" or "-" > > is used to mean an increment/decrement relative to the previous > > value. What misleads me is that the setgain operations are shown > > as implementations of the *1 and *9 requests, which are > > *incremental*. The possibility of misunderstanding could be > > removed by adding a comment. > > > > > [LM2] Good point, especially as I checked our implementation and it > works how I thought, that is, by setting the gain instead of > incrementing/decrementing it. I'll clarify that, to map it to an > incremental operation, it's up to the AS to remember the current > status and modify it accordingly when needed. > > > > (Also, I think that each bullet point should be shown as sentences, > > that is, starting with a capital letter and ending with a period, > > rather than many clauses separated by ";". Here, I have left the > > paragraphs un-filled to make my change clearer; you probably want to > > fill the entire bullet point.) > > > > o The AS ACKs the event (B2), and in its business logic > > understands that the code '*1' means that the UAC wants its own > > volume to be lowered in the conference mix. The AS is able to > > associate the event with the right UAC by referring to the attached > > dialogid (01d1b38). It then acts accordingly, by sending a > > (C1) which does exactly this: the provided > > child element instructs the MS to modify the volume of the > > UAC-->conference audio flow (setgain=-5dB sendonly). > > Notice that the "setgain" value is the absolute volume level; > > if the user's request is to lower the volume level, the AS must > > remember the previously set volume level and from it calculate > > the new volume level. > > Notice how the request also > > includes directives upon the inverse direction. This verbose > > approach is needed, since otherwise the MS would not only > > change the volume in the requested direction, but also disable the > > media flow in the other direction; having a proper > > addressing the UAC<--conf media flow as well ensures that this > > doesn't happen. > > > > Since we have clarified the situation with the first "setgain", > > there is no need to repeat the clarification for the second > > "setgain". > > > > > [LM2] Ok. > > > > > > item 41) section 7.1, section 7.2, section 7.2.1 > > > > [...] > > > > Generally, "AS" and "MS" are used as the plurals of "AS" and > > > > "MS", but in these instances, "ASs" and "MSs" are used. > > > > > > [LM] [...] Besides, ASs sounds really bad... :-) > > > > Ah, yes, I overlooked that. :-) > > > > > > item 46) section 7.2.2.1, section 7.2.2.2 > > > > > > > > Please note that, to ease the reading of the protocol > > > > contents, a simple '=_Part' is used whenever a boundary for a > > > > 'multipart/mixed' payload is provided, instead of the actual > > > > boundary that would be inserted in the SIP messages. > > > > > > > > This seems like a poor strategy, as the resulting figures are > > > > not strictly correct. Perhaps use "Part" as the boundary > > > > value, which would result in figures that look like the > > > > following, which strictly correct and are just as easy to read: > > > > > > > > [..] > > > > Content-Type: multipart/mixed;boundary="Part" > > > > > > > > --Part > > > > Content-Type: application/sdp > > > > > > > > v=0 > > > > o=- 2890844526 2890842807 IN IP4 as.example.com > > > > [...] > > > > > > > > --Part > > > > Content-Type: application/mrb-consumer+xml > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:mrb-consumer"> > > > > [...] > > > > > > > > > > > > --Part-- > > > > > > [LM] I think we did it this way after a comment received on the > > > list: Chris and I did the same for the examples in the MRB draft, > > > for instance. If you think it might improve the readability of the > > > document we'll change this. > > > > I can't find the message that you mention, although the change is > > clear between draft-ietf-mediactrl-mrb-03 and -04. For example: > > > > 1. AS -> MRB (INVITE multipart/mixed) > > ------------------------------------- > > [..] > > Content-Type: multipart/mixed; \ > > boundary="----=_Part_0_19138361.1261662356915" > > > > ------=_Part_0_19138361.1261662356915 > > Content-Type: application/sdp > > > > v=0 > > > > becomes > > > > 1. AS -> MRB (INVITE multipart/mixed) > > ------------------------------------- > > [..] > > Content-Type: multipart/mixed;boundary="=_Part" > > > > =_Part > > Content-Type: application/sdp > > > > v=0 > > > > But you could make the example both easy to read and formally > > correct by just using "Part" as the boundary value (because no body > > line starts with "--Part"): > > > > 1. AS -> MRB (INVITE multipart/mixed) > > ------------------------------------- > > [..] > > Content-Type: multipart/mixed;boundary="Part" > > > > --Part > > Content-Type: application/sdp > > > > v=0 > > > > > [LM2] Ok, I'll fix the boundary in all the examples. > > > > > > item 51) section 7.3.1 > > > > > > > > We might want to mention that in this scenario, the AS obtains > > > > assignment of an MS *before* any UAC makes a request, in order > > > > to have facilities to satisfy future SIP requests. That is > > > > probably how AS's operate in practice, but a naive reader might > > > > expect that the AS will make the consumer request only after > > > > the AS receives a demand for its services. > > > > > > [LM] Actually both Fig.53 and 54 show the AS creating a control > > > channel before receiving an INVITE from the UAC. Or was your point > > > about a different aspect? > > > > I think my point was that you might want to call out in the text > > that the AS creates a control channel to a chosen MS *before* it > > has any requests to service. > > > > > [LM2] Ok, I'll clarify this at the beginning of the section. > > > > > > item 53) section 7.3.2 > > > > > > > > While apparently not a problem, this raises an issue when the > > > > same unaware AS has several sessions with different MS: the AS > > > > would only see one "virtual" MS (the MRB) and so it would relay > > > > all calls there, making it hard for the MRB to understand where > > > > these media dialogs should belong: specifically, whether the UAC > > > > calling belongs to the AS application logic leading to MS1 or > > > > MS2, or wherever else. > > > > > > > > This seems to be a deficiency in the CFW protocol: If the AS > > > > establishes a CFW channel with the MS (via a SIP URI to an MRB), > > > > and then later the AS wants to addresses a SIP INVITE to the MS, > > > > it has no choice but to use the same SIP URI (which routes to > > > > the MRB). This makes it impossible for the MRB to associate > > > > the SIP INVITE with the CFW connection, and thus it is > > > > difficult for the MRB to route the INVITE to the same MS. > > > > > > > > What seems to be needed is for either the COMEDIA response > > > > (application/cfw) or CFW connection to provide a SIP URI that is > > > > the "real" SIP URI of the far-end of the CFW channel. > > > > > > > > Actually, this seems to be a problem even if an AS is addressing > > > > an MS URI, but the URI resolves to a redundant set of MSs: > > > > There seems to be no way to ensure that when a CFW channel is > > > > established that a subsequent SIP INVITE can be sent to the same > > > > MS. This issue seems to be discussed in RFC 6230 section 3, but > > > > I can't find any solution there. > > > > > > [LM] The way it works now is that, for a specific MS, the same SIP > > > URI is used for both negotiating a control channel and attaching > > > media dialogs, yes. A way to overcome this may having the MS > > > redirect media dialogs to a different SIP URI when it receives > > > them (that is, treat control and media dialogs differently) but I > > > realize how this sounds like an implementation hack rather than a > > > real solution. > > > > If an AS is contacting an MS directly, then there is not much of a > > problem with the AS using the same URI for negotiating CFW and for > > establishing SIP dialogs. But if the AS is contacting an MRB and > > the MRB is contacting an MS, when the MRB receives the SIP INVITE, > > it must be able to determine that the AS wants to have the INVITE > > forwarded to the same MS to which the MRB forwarded the CFW > > previously. How does the MRB determine that the AS intends the > > INVITE to go to the same destination as a particular CFW channel? > > > > > [LM2] If I recall correctly, we discussed this a few meetings ago, in > Anaheim, when I presented the MRB draft. The discussion eventually > resulted in sections 5.3 and 6 of the new MRB RFC > (http://tools.ietf.org/html/rfc6917). This is a link to the minutes: > > http://www.ietf.org/proceedings/77/minutes/mediactrl.htm > > Considering it's the MRB that sends back the addresses to use to reach > the MS, if it wants to be in the signalling path, it can return > different SIP URIs, all managed by the MRB, that internally map to the > actual MS endpoints. If I'm not wrong, you also suggested using > something like SIP URI tags to make this work, but I can't find a > match in the minutes. Anyway, the issue is broader when you have the > MRB acting as a B2BUA rather than a proxy, as in that case you risk > ending up messing the connectionid identifiers that are used to > address media connections. > > > > > > item 55) section 8 > > > > > > > > The detailed discussion of how the MS enforces security against > > > > the ASs is helpful, but it does not mention how the MS discerns > > > > which requests come from AS1 and which come from AS2. > > > > I did not see a response to this issue. > > > > > [LM2] The AS and MS do a SYNC when they first set up the control > channel, and since it involves info coming from the SDP that allows a > MS to know that TCP connection comes from an AS in particular. Do you > think this needs to be clarified in the document? I'll add some brief > text to make this clearer. > > > Thanks! > Lorenzo > > > > ---------------------------------------------------------------------- > > > > Summary of uses of "comedia" in published RFCs > > > > RFC 4145 does not contain the term "comedia" at all, although its > > short title is "Connection-Oriented Media". > > > > RFC 4571 uses "comedia" only as the name of a Normative Reference to > > RFC 4145. > > > > RFC 4572 uses "comedia" only in the short title, "Comedia over TLS > > in SDP". > > > > RFC 4975 uses "comedia" only in this sentence: > > > > The mechanism was loosely based on the Connection-Oriented Media > > (COMEDIA) [26] work done by the MMUSIC working group. > > > > Reference [26] is RFC 4145. > > > > RFC 5567 uses "comedia" only in this sentence: > > > > [RFC4583] provides a way for SIP UAs to set up a BFCP connection > > towards the Floor Control Server and exploit floor control by > > means of a Connection-Oriented Media (COMEDIA) [RFC4145] > > negotiation. > > > > RFC 5631 uses "comedia" only in these two sentences: > > > > This problem could be solved through the use of > > Connection-Oriented Media (COMEDIA) [26], which specifies the > > "setup" SDP attribute to negotiate these roles. > > > > Assuming it agreed to such a session, it responds with a "setup" > > attribute, as per the COMEDIA specifications. > > > > Reference [26] is RFC 4145. > > > > RFC 6135 uses "comedia" in many places, and includes a definition of > > it in the abstract: > > > > [...] this model uses the connection-oriented media (COMEDIA) > > mechanism in order to create the MSRP transport connection. The > > model allows MSRP UAs behind Network > > > > RFC 6193 uses "comedia" only within the term "comedia-tls", which is > > defined as: > > > > [...] "Connection-Oriented Media Transport over the Transport > > Layer Security (TLS) Protocol in the Session Description Protocol > > (SDP)" [RFC4572] (hereafter referred to as comedia-tls) [...] > > > > RFC 6230 uses "comedia" to refer to RFC 4145, and to the SDP > > attribute "a=setup". > > > > The Connection-Oriented Media (COMEDIA) [RFC4145] specification > > for setting up and maintaining reliable connections is used as part > > of the negotiation mechanism (more detail available in later > > sections). > > > > If the Client initiating the SDP offer has a COMEDIA 'setup' > > attribute equal to active, [...] > > > > RFC 6787 uses "comedia" to refer to RFC 4572: > > > > When using TLS, the SDP "m=" line for the control stream MUST > > conform to Connection-Oriented Media (COMEDIA) over TLS > > [RFC4572], which specifies the usage of SDP for establishing a > > secure connection-oriented transport over TLS. > > > > RFC 6917 uses "comedia" in two places to refer to SDP support for > > connection-oriented media. > > > > ---------------------------------------------------------------------- > > > > Dale > > _______________________________________________ > > MEDIACTRL mailing list > > MEDIACTRL@ietf.org > > https://www.ietf.org/mailman/listinfo/mediactrl > > Supplemental Web Site: > > http://www.standardstrack.com/ietf/mediactrl > > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl From johnsonhammond1@hushmail.com Sat Apr 27 15:47:31 2013 Return-Path: X-Original-To: mediactrl@ietfa.amsl.com Delivered-To: mediactrl@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B9621F992E for ; Sat, 27 Apr 2013 15:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5zt9wtiiM86 for ; Sat, 27 Apr 2013 15:47:29 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4DA21F990F for ; Sat, 27 Apr 2013 15:47:28 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id E37DC580AE for ; Sat, 27 Apr 2013 17:40:10 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:40:10 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A0DBFE6736; Sat, 27 Apr 2013 17:40:10 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:40:10 -0400 To: mediactrl@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174010.A0DBFE6736@smtp.hushmail.com> Subject: [MEDIACTRL] Biggest Fake Conference in Computer Science X-BeenThere: mediactrl@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Control WG Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 22:47:31 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.