Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10
Lorenzo Miniero <lorenzo@meetecho.com> Wed, 17 April 2013 15:24 UTC
Return-Path: <lorenzo@meetecho.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 70D2F21E8089 for <mediactrl@ietfa.amsl.com>; Wed, 17 Apr 2013 08:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD26+9F3o+g2 for <mediactrl@ietfa.amsl.com>; Wed, 17 Apr 2013 08:24:10 -0700 (PDT)
Received: from smtpdg11.aruba.it (smtpdg6.aruba.it [62.149.158.236]) by ietfa.amsl.com (Postfix) with ESMTP id 81F8A21F871C for <mediactrl@ietf.org>; Wed, 17 Apr 2013 08:24:08 -0700 (PDT)
Received: from lminiero ([143.225.229.185]) by smtpcmd04.ad.aruba.it with bizsmtp id R3Q41l00z40f7Ln013Q4V9; Wed, 17 Apr 2013 17:24:05 +0200
Date: Wed, 17 Apr 2013 17:24:04 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: worley@ariadne.com
Message-ID: <20130417172404.4b64082d@lminiero>
In-Reply-To: <201304152148.r3FLmKaO2695748@shell01.TheWorld.com>
References: <201212192009.qBJK9j8a3356324@shell01.TheWorld.com> <20121226131152.4660538e@rainpc> <97700AB5-E682-4DA2-BCD6-874A50F66575@standardstrack.com> <201304152148.r3FLmKaO2695748@shell01.TheWorld.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; i686-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] Review of draft-ietf-mediactrl-call-flows-10
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <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: Wed, 17 Apr 2013 15:24:13 -0000
Hello Dale, thanks for the additional comments, I've added some replies inline prefixed by [LM2], L. Il giorno Mon, 15 Apr 2013 17:48:20 -0400 (EDT) worley@ariadne.com (Dale R. Worley) ha scritto: > > From: Eric Burger <eburger@standardstrack.com> > > > > Are we done yet? > > Looking over the messages, I see that I should have responded to > Lorenzo's message of 26 Dec > (http://www.ietf.org/mail-archive/web/mediactrl/current/msg01781.html). > Of course, most of the items have already been resolved, but there are > a few that need more discussion. > > > > item 1) various > > > > > > The indentation of the header lines identifying various messages > > > is inconsistent. I can find the following lines in various > > > places: > > [...] > > > > [LM] You're right, the indentation often varies, and the logic > > behind this currently is according to whether or not the example > > fits the page. Instructions about this would be welcome! > > I think leaving it to the Editor may be the best, and the Editor will > have to worry about fitting the lines on the page anyway. The Editor > probably as style conventions about indenting. > [LM2] Ok. > > > item 2) various > > > > > > There are a lot of places where an arrow seems to go from a > > > network entity to itself, such as "create conf and its ID" below: > > > > > > AS MS > > > | | > > > | 1. CONTROL (create conference) | > > > |++++++++++++++++++++++++++++++++>>| > > > | |--+ create > > > | | | conf > > > and | 2. 200 OK (conferenceid=Y) |<-+ its ID > > > |<<++++++++++++++++++++++++++++++++| > > > > [LM] Yes, in that case the arrow was not meant as a network > > connection, but as a further step in the sequence diagram, that is > > what that CONTROL message triggers in the MS application logic. The > > same applies to all the examples where this happens. If you think > > the arrowless diagram is clearer to the reader we might remove > > them: the problem with this is that, without arrows, some diagrams > > might be harder to read, i.e., in terms of who does what in > > diagrams with several components interacting with each other. As an > > alternative, we might clarify what those arrows are and what they > > are not. What do you think about this? > > We might be able to choose a syntax that less resembles the > propagation of a message. Perhaps this: > > AS MS > | | > | 1. CONTROL (create conference) | > |++++++++++++++++++++++++++++++++>>| > | |-- create > | | conf and > | | its ID > | 2. 200 OK (conferenceid=Y) | > |<<++++++++++++++++++++++++++++++++| > > That makes it clear that the MS is performing an action, but it does > not look like generating a message. > [LM2] I've added some text in the "Conventions" section to clarify what those arrows mean: Besides, also note that a few diagrams present arrows that go from a network entity to itself. It's worth pointing out that such arrows do not represent any transaction message, but are rather meant as an indication to the reader that the involved network entity took a decision, within its application logic, according to the input it previously received. Do you think that may suffice? > > > item 7) section 4 > > > > > > This section starts with a paragraph over one page long. Could > > > it be broken into multiple paragraphs? > > > > [LM] Did you mean section 4.1? Section 4 starts with just a few > > lines. > > Yes, you are right, I meant section 4.1. > [LM2] Ok, I'll try and make it more readable. > > > item 9) section 4 figure 1 > > > [...] > > > - The states "'202' sent" and "'update' sent" have the same > > > outgoing transitions, so they should probably be merged. > > > > [LM] I'm not sure about this: 202 is only sent after the first > > CONTROL message to tell the AS it may take a while to process the > > request, after which you can either have further 202 messages > > should the processing take even more time, or one or more UPDATE > > messages related to that CONTROL request after that. They're two > > different messages in the protocol semantics. Nevertheless, it's > > also true that, according to RFC6230, a 202 is basically a > > pre-REPORT message... any feedback on this? > > The idea is that the MS is in the same state after sending the 202 as > it is after sending a subsequent update, because what it can do next > is the same, and so at least theoretically, the two states do not need > to be distinguished. > > My idea is that the diagram could be simplified to look like this: > > +------------------+ CONTROL/- +------------------+ API 202/202 > | Idle/'terminate' |------------>| CONTROL received |---------+ > +------------------+ +------------------+ | > ^ ^ ^ | | | > | | | API 200/200 | | | > | | +------------------+ | | > | 200/- | API Error/Error | | > | +----------------------------+ | > | | > | | > | API terminate/ v > +------------------+ REPORT terminate > +-------------------+ | 'terminate' sent > |<--------------------------| command executing | > +------------------+ +-------------------+ > ^ | | | API update/ > | | > REPORT update | | > | | > | | > 200/- | | > | v > +---------------+ > | 'update' sent | > +---------------+ > [LM2] That indeed looks much "cleaner" than what we have now. I'll have to check whether it actually addresses all the transitions we envisaged when first drawing the diagram that ended up in the draft. > > > item 9) section 4 figure 1 > > > [...] > > > - What happens if the API detects an error after 202 has been > > > sent? There is no "API Error" arc from "'202' sent"/"'update' > > > confirmed". > > > > [LM] Good point. The idea is that, once the MS sends a 202, the > > request has been correctly processed, and so is supposed to be fine > > as far as the protocol is concerned. I guess there could be > > circumstances when an errors occurs after that, e.g., in retrieving > > an audio file to be played to a UAC: in that case, the AS would be > > informed of the termination of the dialog/request in a REPORT > > terminate, including details on the issue which are Control Package > > specific. Do you think explaining this in the text may help readers? > > I think an explanation in the text would be helpful, although if the > reader has a thorough understanding of what information is carried in > REPORT terminate they would deduce the answer. Perhaps this > explanation would help those who are not completely familiar: > > The MS may send a 202 response after it determines that the request > request contains no errors that cannot be reported in a later > REPORT terminate request. After the MS sends a 202 response, any > error that it (or the API) finds in the request is reported in the > final REPORT terminate request. > [LM2] Thanks, I've added the explaination in place of the text I put there in the latest version, as yours is clearer. > > > item 12) section 5 > > > > > > The term "COMEDIA" is used, and a reference is given to RFC > > > 4145. But that RFC does not use the term "COMEDIA" at all. The > > > framework I-D also uses "COMEDIA" without explicitly defining > > > it. It would be helpful to insert here a definition of > > > "COMEDIA", which seems to be synonymous with "media of type > > > application/cfw". > > > > [LM] I thought COMEDIA actually came from RFC4145, standing for > > "connection-oriented media". Even the MSRP RFC refers to it that > > way. If that's incorrect or incomplete we'll fix this in the next > > version. > > I've searched through all the RFCs for the term "comedia". (The > results are summarized at the end of this message.) What seems to > have happened is that "comedia" has become an abbreviation for > "connection-oriented media" (i.e., TCP and TLS) and also for two RFCs > regarding support for connection-oriented media (RFC 4145 and RFC > 4572). > > The problem is that the term seems to be very common among a small > audience centered on Mediactrl, but only among that audience, and > people inside that audience do not take care to define it clearly for > the benefit of people outside that audience. For instance, RFC 5567 > is "An Architectural Framework for Media Server Control" and uses > "comedia" in "... exploit floor control by means of a > Connection-Oriented Media (COMEDIA) [RFC4145] negotiation." but > "comedia" is not listed in its section 2, "Terminology". > > I think this would be solved if "comedia" was listed in section 3, > "Terminology": > > COMEDIA: connection-oriented media (i.e., TCP and TLS). Also > used to signify the support in SDP for connection-oriented media, and > the RFCs that define that support (RFC 4145 and RFC 4572). > [LM2] Ok, I already expanded COMEDIA upon its first occurrence, but also specifying it in the terminology is probably better. > > > item 15) section 5.1 > > > > [...] > > > This confuses me: Either the list of packages in the SDP > > > offer/answer is significant or it is not. If it is not, why is > > > it provided? [...] > > > > [LM] That section refers to a draft Chris submitted to the MMUSIC WG > > some time ago: > > > > http://tools.ietf.org/html/draft-boulton-mmusic-sdp-control-package-attribute-07 > > > > so any clarification about the purpose and constraints of such a > > mechanism should be addressed in the specification. Chris, do you > > think this behaviour could be clarified in the draft, in order to > > have it reflected in the Call Flows as a consequence? > > This looks complicated. It seems that > draft-boulton-mmusic-sdp-control-package-attribute has not been > adopted as a working group draft and has expired. If that is the > case, there will be no definition of the ctrl-package attribute, and > it shouldn't be used in the call-flows. > > But if that is fixed, it seems that we can copy some text from > draft-boulton-mmusic-sdp-control-package-attribute to clarify this > paragraph. I suggest splitting the paragraph, and amending the second > half like this: > > Note that the provided example also includes the indication, from > both the AS and the MS, of the supported control packages. This is > achieved by means of a series of 'ctrl-package' attributes as > specified in [I-D.boulton-mmusic-sdp-control-package-attribute]. > In the example, the AS supports (or is only interested to) two > packages: IVR (Interactive Voice Response) and Mixer (Conferencing and > Bridging). The MS replies with the list of packages it supports, > adding a dummy example package to the list provided by the AS. > > It is worth noting that this exchange of information is only > advisory and neither endpoint is committing to support the packages > that are listed or to not supporting the packages that are not > listed. The actual negotiation of control packages is done > subsequently through the use of the framework SYNC transaction > within the control channel. Nonetheless, the use of 'ctrl-package' > attributes can be beneficial both from a resource allocation > perspective and it could also result in two clients identifying > they are not capable of successful control channel interactions. > This would lead to early abandonment of control channel setup (for > example, a client may choose to terminate the associated SIP dialog > and not attempt to make the connection). > [LM2] Ok, I'll do something like that should the issue with the expired document be fixed. > > > item 17) section 5.3 > > > > > > In the previous section it has been described how a timeout > > > value for the keep alive mechanism is negotiated. Specifically, > > > in the example the AS and the MS agreed on a value of 100 > > > seconds. > > > > > > In fact, that section does not describe how the value is > > > negotiated (since it is not clear what happens if the MS dislikes > > > the value proposed by the AS). However, this is correct: > > > > > > In example in the previous section, the AS and the MS agreed > > > on a value of 100 seconds. > > > > [LM] According to RFC6230, the 200 to the SYNC MUST have the same > > keep-alive value proposed in the original SYNC. Who sends the SYNC > > can change according to the COMEDIA negotiation. Specifically, "The > > previous steps ensure that the entity initiating the Control > > Channel connection is always the one specifying the keep-alive > > timeout period.". So, to answer your question, I guess that if a MS > > dislikes the value, it can just pick the active role and send a new > > SYNC with a new keep-alive value. > > OK, that was my mistake, as I was confusing how the MRB mechanism > works with the more complicated SIP timeout mechanism. But I think it > could be clarified by changing the two sentences to: > > In the previous section it has been described that the timeout > value for the keep-alive mechanism is set by the SYNC request. > Specifically, in the example the AS specified a value of 100 > seconds. > > In particular, the timeout value is not *negotiated* between the AS > and MS, it is simply specified by whichever endpoint takes the active > role. > [LM2] Ok. > > > item 22) section 6.1.2 > > > > > > The 202+REPORT(s) mechanism is used whenever the MS wants to > > > tell the AS that the requested operation might take some more > > > time than expected. > > > > [LM] Actually, the time is Control Package dependent. Different > > packages may have different timeouts. Quoting the framework, "A > > Control Package MUST explicitly define the circumstances under > > which the server sends 200 and 202 messages." > > Then the situation could be made clearer by writing: > > The 202+REPORT(s) mechanism is used whenever the MS wants to tell > the AS that the requested operation might take more time than > the limit specified in the definition of the Control Package. > [LM2] Ok. > > > item 23) section 6.2 figure 18 > > > > > > It might be useful to distinguish the four(?) SIP dialogs > > > involved. > > > > [LM] Do you mean as in different figures? or clearer text? > > I made a mistake there; I should have said "figure 17". > > The figure is a bit confusing, as there are either 3 or 4 SIP dialogs > involved, and the SIP messages are not marked to show which dialog > they are within. (Depending on how the AS functions, the SIP from > UAC2 to AS may or may not be within the same dialog as the SIP from > UAC1 to AS.) Someone familiar with AS/MS operation can guess which > messages are part of which dialogs, but it may be confusing for those > who are not familiar. It might not be important in this context, but > in RFCs that come out of the SIP WGs, in a situation like this, the > different SIP dialogs are distinguished by specifying Call-Id values. > In this case, figure 17 would look like this: > > UAC(1) UAC(2) AS > MS | | | | > | INVITE (offer A) | | > | Call-Id: A | | | > |---------------------------------->| | > | | 100 Trying | | > | | Call-Id: A | | > |<----------------------------------| | > | | INVITE (no offer) | | > | | Call-Id: B | | > | |<--------------------| | > | | 180 Ringing | | > | | Call-Id: B | | > | |-------------------->| | > | | 180 Ringing | | > | | Call-Id: A | | > |<----------------------------------| | > | | | INVITE (offer A) | > | | | Call-Id: C | > | | |-------------------------->| > | | | 200 OK (offer A') | > | | | Call-Id: C | > | | |<--------------------------| > | | | ACK | > | | | Call-Id: C | > | | |-------------------------->| > | | 200 OK (offer B) | | > | | Call-Id: B | | > | |-------------------->| | > | | | INVITE (offer B) | > | | | Call-Id: D | > | | |-------------------------->| > | | | 200 OK (offer B') | > | | | Call-Id: D | > | | |<--------------------------| > | | | ACK | > | | | Call-Id: D | > | | |-------------------------->| > | | ACK (offer B') | | > | | Call-Id: B | | > | |<--------------------| | > | | 200 OK (offer A') | | > | | Call-Id: A | | > |<----------------------------------| | > | ACK | | | > | Call-Id: A | | | > |---------------------------------->| | > | | | | > . . . . > . . . . > > (If the AS acts like a proxy between UAC1 and UAC2 rather than a > B2BUA, then "Call-Id: B" is replaced with "Call-Id: A" throughout.) > [LM2] Thanks for the hint, I've updated the diagram. > > > item 35) section 6.4 > > > > > > The discussion of mixing in the background music should be > > > contrasted with the mixing of the two recordings during playback > > > in section 6.2.3. Naively, it would seem that the same mixing > > > techniques could be used in both cases, but the two sections > > > implement mixing in entirely different ways. > > > > [LM] Are you talking of 6.4.2 (current time example)? If so, this > > was done on purpose, to exploit two different scenarios to showcase > > the use of two different techniques. You're right in saying that > > the same could be applied to both cases, nothing naive in this :-) > > OK, I see the point of the example. > > But I see another issue: It might help to add to section 3: > > VCR controls: runtime control of aspects of an audio playback like > speed and volume, via DTMF signals sent by the user, in a > manner that resembles the functions of a VCR (video cassette > recorder) controller. > [LM2] Ok. > > > item 36) section 6.4.3 > > > > > > An example contains XML elements that seem to be unnecessarily > > > complex: > > > > > > <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! > > Yes, let us ask implementers what they think is clearer. > > > > item 38) section 6.4.3 > > > > > > This section leads to a question about the semantics of the > > > <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? > > Now that I think about it more, I think the usual terminology is that > the gain is seen as the difference between the input and the output, > and "setting" it means fixing the gain at a specific number. However, > in many usages, a number prefixed by "+" or "-" is used to mean an > increment/decrement relative to the previous value. What misleads me > is that the setgain operations are shown as implementations of the *1 > and *9 requests, which are *incremental*. The possibility of > misunderstanding could be removed by adding a comment. > [LM2] Good point, especially as I checked our implementation and it works how I thought, that is, by setting the gain instead of incrementing/decrementing it. I'll clarify that, to map it to an incremental operation, it's up to the AS to remember the current status and modify it accordingly when needed. > (Also, I think that each bullet point should be shown as sentences, > that is, starting with a capital letter and ending with a period, > rather than many clauses separated by ";". Here, I have left the > paragraphs un-filled to make my change clearer; you probably want to > fill the entire bullet point.) > > o The AS ACKs the event (B2), and in its business logic > understands that the code '*1' means that the UAC wants its own > volume to be lowered in the conference mix. The AS is able to > associate the event with the right UAC by referring to the attached > dialogid (01d1b38). It then acts accordingly, by sending a > <modifyjoin> (C1) which does exactly this: the provided <stream> > child element instructs the MS to modify the volume of the > UAC-->conference audio flow (setgain=-5dB sendonly). > Notice that the "setgain" value is the absolute volume level; if > the user's request is to lower the volume level, the AS must > remember the previously set volume level and from it calculate > the new volume level. > Notice how the request also > includes directives upon the inverse direction. This verbose > approach is needed, since otherwise the MS would not only change > the volume in the requested direction, but also disable the > media flow in the other direction; having a proper <stream> addressing > the UAC<--conf media flow as well ensures that this doesn't > happen. > > Since we have clarified the situation with the first "setgain", there > is no need to repeat the clarification for the second "setgain". > [LM2] Ok. > > > item 41) section 7.1, section 7.2, section 7.2.1 > > > [...] > > > Generally, "AS" and "MS" are used as the plurals of "AS" and > > > "MS", but in these instances, "ASs" and "MSs" are used. > > > > [LM] [...] Besides, ASs sounds really bad... :-) > > Ah, yes, I overlooked that. :-) > > > > item 46) section 7.2.2.1, section 7.2.2.2 > > > > > > Please note that, to ease the reading of the protocol > > > contents, a simple '=_Part' is used whenever a boundary for a > > > 'multipart/mixed' payload is provided, instead of the actual > > > boundary that would be inserted in the SIP messages. > > > > > > This seems like a poor strategy, as the resulting figures are not > > > strictly correct. Perhaps use "Part" as the boundary value, which > > > would result in figures that look like the following, which > > > strictly correct and are just as easy to read: > > > > > > [..] > > > Content-Type: multipart/mixed;boundary="Part" > > > > > > --Part > > > Content-Type: application/sdp > > > > > > v=0 > > > o=- 2890844526 2890842807 IN IP4 as.example.com > > > [...] > > > > > > --Part > > > Content-Type: application/mrb-consumer+xml > > > > > > <?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 readability of the > > document we'll change this. > > I can't find the message that you mention, although the change is > clear between draft-ietf-mediactrl-mrb-03 and -04. For example: > > 1. AS -> MRB (INVITE multipart/mixed) > ------------------------------------- > [..] > Content-Type: multipart/mixed; \ > boundary="----=_Part_0_19138361.1261662356915" > > ------=_Part_0_19138361.1261662356915 > Content-Type: application/sdp > > v=0 > > becomes > > 1. AS -> MRB (INVITE multipart/mixed) > ------------------------------------- > [..] > Content-Type: multipart/mixed;boundary="=_Part" > > =_Part > Content-Type: application/sdp > > v=0 > > But you could make the example both easy to read and formally correct > by just using "Part" as the boundary value (because no body line > starts with "--Part"): > > 1. AS -> MRB (INVITE multipart/mixed) > ------------------------------------- > [..] > Content-Type: multipart/mixed;boundary="Part" > > --Part > Content-Type: application/sdp > > v=0 > [LM2] Ok, I'll fix the boundary in all the examples. > > > item 51) section 7.3.1 > > > > > > We might want to mention that in this scenario, the AS obtains > > > assignment of an MS *before* any UAC makes a request, in order to > > > have facilities to satisfy future SIP requests. That is probably > > > how AS's operate in practice, but a naive reader might expect > > > that the AS will make the consumer request only after the AS > > > receives a demand for its services. > > > > [LM] Actually both Fig.53 and 54 show the AS creating a control > > channel before receiving an INVITE from the UAC. Or was your point > > about a different aspect? > > I think my point was that you might want to call out in the text that > the AS creates a control channel to a chosen MS *before* it has any > requests to service. > [LM2] Ok, I'll clarify this at the beginning of the section. > > > item 53) section 7.3.2 > > > > > > While apparently not a problem, this raises an issue when the > > > same unaware AS has several sessions with different MS: the AS > > > would only see one "virtual" MS (the MRB) and so it would relay > > > all calls there, making it hard for the MRB to understand where > > > these media dialogs should belong: specifically, whether the UAC > > > calling belongs to the AS application logic leading to MS1 or > > > MS2, or wherever else. > > > > > > This seems to be a deficiency in the CFW protocol: If the AS > > > establishes a CFW channel with the MS (via a SIP URI to an MRB), > > > and then later the AS wants to addresses a SIP INVITE to the MS, > > > it has no choice but to use the same SIP URI (which routes to the > > > MRB). This makes it impossible for the MRB to associate the SIP > > > INVITE with the CFW connection, and thus it is difficult for the > > > MRB to route the INVITE to the same MS. > > > > > > What seems to be needed is for either the COMEDIA response > > > (application/cfw) or CFW connection to provide a SIP URI that is > > > the "real" SIP URI of the far-end of the CFW channel. > > > > > > Actually, this seems to be a problem even if an AS is addressing > > > an MS URI, but the URI resolves to a redundant set of MSs: There > > > seems to be no way to ensure that when a CFW channel is > > > established that a subsequent SIP INVITE can be sent to the same > > > MS. This issue seems to be discussed in RFC 6230 section 3, but > > > I can't find any solution there. > > > > [LM] The way it works now is that, for a specific MS, the same SIP > > URI is used for both negotiating a control channel and attaching > > media dialogs, yes. A way to overcome this may having the MS > > redirect media dialogs to a different SIP URI when it receives them > > (that is, treat control and media dialogs differently) but I > > realize how this sounds like an implementation hack rather than a > > real solution. > > If an AS is contacting an MS directly, then there is not much of a > problem with the AS using the same URI for negotiating CFW and for > establishing SIP dialogs. But if the AS is contacting an MRB and the > MRB is contacting an MS, when the MRB receives the SIP INVITE, it must > be able to determine that the AS wants to have the INVITE forwarded to > the same MS to which the MRB forwarded the CFW previously. How does > the MRB determine that the AS intends the INVITE to go to the same > destination as a particular CFW channel? > [LM2] If I recall correctly, we discussed this a few meetings ago, in Anaheim, when I presented the MRB draft. The discussion eventually resulted in sections 5.3 and 6 of the new MRB RFC (http://tools.ietf.org/html/rfc6917). This is a link to the minutes: http://www.ietf.org/proceedings/77/minutes/mediactrl.htm Considering it's the MRB that sends back the addresses to use to reach the MS, if it wants to be in the signalling path, it can return different SIP URIs, all managed by the MRB, that internally map to the actual MS endpoints. If I'm not wrong, you also suggested using something like SIP URI tags to make this work, but I can't find a match in the minutes. Anyway, the issue is broader when you have the MRB acting as a B2BUA rather than a proxy, as in that case you risk ending up messing the connectionid identifiers that are used to address media connections. > > > item 55) section 8 > > > > > > The detailed discussion of how the MS enforces security against > > > the ASs is helpful, but it does not mention how the MS discerns > > > which requests come from AS1 and which come from AS2. > > I did not see a response to this issue. > [LM2] The AS and MS do a SYNC when they first set up the control channel, and since it involves info coming from the SDP that allows a MS to know that TCP connection comes from an AS in particular. Do you think this needs to be clarified in the document? I'll add some brief text to make this clearer. Thanks! Lorenzo > ---------------------------------------------------------------------- > > Summary of uses of "comedia" in published RFCs > > RFC 4145 does not contain the term "comedia" at all, although its > short title is "Connection-Oriented Media". > > RFC 4571 uses "comedia" only as the name of a Normative Reference to > RFC 4145. > > RFC 4572 uses "comedia" only in the short title, "Comedia over TLS in > SDP". > > RFC 4975 uses "comedia" only in this sentence: > > The mechanism was loosely based on the Connection-Oriented Media > (COMEDIA) [26] work done by the MMUSIC working group. > > Reference [26] is RFC 4145. > > RFC 5567 uses "comedia" only in this sentence: > > [RFC4583] provides a way for SIP UAs to set up a BFCP connection > towards the Floor Control Server and exploit floor control by means > of a Connection-Oriented Media (COMEDIA) [RFC4145] negotiation. > > RFC 5631 uses "comedia" only in these two sentences: > > This problem could be solved through the use of Connection-Oriented > Media (COMEDIA) [26], which specifies the "setup" SDP attribute to > negotiate these roles. > > Assuming it agreed to such a session, it responds with a "setup" > attribute, as per the COMEDIA specifications. > > Reference [26] is RFC 4145. > > RFC 6135 uses "comedia" in many places, and includes a definition of > it in the abstract: > > [...] this model uses the connection-oriented media (COMEDIA) > mechanism in order to create the MSRP transport connection. The > model allows MSRP UAs behind Network > > RFC 6193 uses "comedia" only within the term "comedia-tls", which is > defined as: > > [...] "Connection-Oriented Media Transport over the Transport > Layer Security (TLS) Protocol in the Session Description Protocol > (SDP)" [RFC4572] (hereafter referred to as comedia-tls) [...] > > RFC 6230 uses "comedia" to refer to RFC 4145, and to the SDP attribute > "a=setup". > > The Connection-Oriented Media (COMEDIA) [RFC4145] specification for > setting up and maintaining reliable connections is used as part of > the negotiation mechanism (more detail available in later > sections). > > If the Client initiating the SDP offer has a COMEDIA 'setup' > attribute equal to active, [...] > > RFC 6787 uses "comedia" to refer to RFC 4572: > > When using TLS, the SDP "m=" line for the control stream MUST > conform to Connection-Oriented Media (COMEDIA) over TLS [RFC4572], > which specifies the usage of SDP for establishing a secure > connection-oriented transport over TLS. > > RFC 6917 uses "comedia" in two places to refer to SDP support for > connection-oriented media. > > ---------------------------------------------------------------------- > > Dale > _______________________________________________ > MEDIACTRL mailing list > MEDIACTRL@ietf.org > https://www.ietf.org/mailman/listinfo/mediactrl > Supplemental Web Site: > http://www.standardstrack.com/ietf/mediactrl
- [MEDIACTRL] 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