Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10

Eric Burger <eburger@standardstrack.com> Sat, 13 April 2013 06:57 UTC

Return-Path: <eburger@standardstrack.com>
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 <mediactrl@ietfa.amsl.com>; 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 <mediactrl@ietfa.amsl.com>; 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 <mediactrl@ietf.org>; 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 <eburger@standardstrack.com>) 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 <eburger@standardstrack.com>
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 <lorenzo@meetecho.com>
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" <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 <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=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 <lorenzo@meetecho.com>; 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)
>> 
>>      <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
>>         <join id1="2f5ad43" id2="519c1b9">
>>            <stream media="audio" direction="sendonly">
>>               <volume controltype="setgain" value="-5"/>
>>            </stream>
>>         </join>
>>      </mscmixer>
>> 
>> 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:
>> 
>>       <rule id="action" scope="public">
>>         <item>
>>           *
>>           <item><ruleref uri="#digit"/></item>
>>         </item>
>>       </rule>
>> 
>> As far as I can tell from the SRGS specification, <item> 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 <one-of> element, or (3) constructing
>> the "null" regular expression (that consumes no input and always
>> matches).  Thus, these examples can be simplified to:
>> 
>>       <rule id="action" scope="public">
>>         *
>>         <ruleref uri="#digit"/>
>>       </rule>
>> 
>> 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 <collect>, 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 <volume
>> controltype="setgain" ...> operation:  Clearly, initially the stream
>> is output at the same volume as the input media.  But when "<volume
>> 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:
>> 
>>        <mixing-modes>
>>            <audio-mixing-modes>
>>                <audio-mixing-mode package="msc-ivr/1.0">
>>                     nbest
>>                </audio-mixing-mode>
>>            </audio-mixing-modes>
>>            <video-mixing-modes activespeakermix="true" vas="true">
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     single-view
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     dual-view
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     dual-view-crop
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     dual-view-2x1
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     dual-view-2x1-crop
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     quad-view
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     multiple-5x1
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     multiple-3x3
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0">
>>                     multiple-4x4
>>                </video-mixing-mode>
>>            </video-mixing-modes>
>>        </mixing-modes>
>> 
>> 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:
>> 
>>        <mixing-modes>
>>            <audio-mixing-modes>
>>                <audio-mixing-mode package="msc-ivr/1.0"> \
>>                     nbest \
>>                </audio-mixing-mode>
>>            </audio-mixing-modes>
>>            <video-mixing-modes activespeakermix="true" vas="true">
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     single-view \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     dual-view \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     dual-view-crop \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     dual-view-2x1 \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     dual-view-2x1-crop \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     quad-view \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     multiple-5x1 \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     multiple-3x3 \
>>                </video-mixing-mode>
>>                <video-mixing-mode package="msc-mixer/1.0"> \
>>                     multiple-4x4 \
>>                </video-mixing-mode>
>>            </video-mixing-modes>
>>        </mixing-modes>
>> 
> 
> 
> [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
>> 
>>   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>   <mrbconsumer version="1.0"
>>                xmlns="urn:ietf:params:xml:ns:mrb-consumer">
>>      [...]
>>   </mrbconsumer>
>> 
>>   --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