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
- [MEDIACTRL] Review of draft-ietf-mediactrl-call-f… Dale R. Worley
- Re: [MEDIACTRL] Review of draft-ietf-mediactrl-ca… Lorenzo Miniero
- Re: [MEDIACTRL] Review of draft-ietf-mediactrl-ca… Eric Burger
- Re: [MEDIACTRL] Review of draft-ietf-mediactrl-ca… Lorenzo Miniero
- Re: [MEDIACTRL] Review of draft-ietf-mediactrl-ca… Lorenzo Miniero
- Re: [MEDIACTRL] Review of draft-ietf-mediactrl-ca… Dale R. Worley
- Re: [MEDIACTRL] Review of draft-ietf-mediactrl-ca… Lorenzo Miniero
- Re: [MEDIACTRL] Review of draft-ietf-mediactrl-ca… Lorenzo Miniero