Media Control Channel Framework (CFW) Call Flow Examples
draft-ietf-mediactrl-call-flows-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-11-08
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-10-29
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-10-15
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2013-10-14
|
13 | (System) | RFC Editor state changed to AUTH from EDIT |
2013-09-19
|
13 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2013-09-18
|
13 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-09-17
|
13 | (System) | RFC Editor state changed to EDIT |
2013-09-17
|
13 | (System) | Announcement was received by RFC Editor |
2013-09-16
|
13 | (System) | IANA Action state changed to No IC from In Progress |
2013-09-16
|
13 | (System) | IANA Action state changed to In Progress |
2013-09-16
|
13 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-09-16
|
13 | Amy Vezza | IESG has approved the document |
2013-09-16
|
13 | Amy Vezza | Closed "Approve" ballot |
2013-09-16
|
13 | Amy Vezza | Ballot writeup was changed |
2013-09-12
|
13 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation |
2013-09-12
|
13 | Barry Leiba | [Ballot comment] I'm intentionally staying with "no position" on this, rather than deferring it, as Richard has assured me that a sufficient number of the … [Ballot comment] I'm intentionally staying with "no position" on this, rather than deferring it, as Richard has assured me that a sufficient number of the right set of eyes have been on it, and as I trust my fellow ADs to have it covered. |
2013-09-12
|
13 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2013-09-12
|
13 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-09-12
|
13 | Sean Turner | [Ballot comment] s7.2.1: "mess with" could be better phrased ;) |
2013-09-12
|
13 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-09-12
|
13 | Stephen Farrell | [Ballot comment] - Some of the tools page links seem to be broken by the formatting used, e.g. [1] doesn't go to the security considerations. … [Ballot comment] - Some of the tools page links seem to be broken by the formatting used, e.g. [1] doesn't go to the security considerations. Not sure if that's easy to fix or worth fixing though. [1] http://tools.ietf.org/html/draft-ietf-mediactrl-call-flows-13#section-8 - "variegated bouquet of services": heh, not many RFCs have those:-) |
2013-09-12
|
13 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-09-12
|
13 | Stewart Bryant | [Ballot comment] I am taking a position of no objection based on a quick look which indicated that this text has no impact on Routing. |
2013-09-12
|
13 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-09-12
|
13 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-09-11
|
13 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-09-09
|
13 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-09-08
|
13 | Brian Carpenter | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Brian Carpenter. |
2013-09-06
|
13 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2013-09-05
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2013-09-05
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2013-09-05
|
13 | Richard Barnes | Ballot has been issued |
2013-09-05
|
13 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-09-05
|
13 | Richard Barnes | Created "Approve" ballot |
2013-09-05
|
13 | Richard Barnes | Placed on agenda for telechat - 2013-09-12 |
2013-09-05
|
13 | Richard Barnes | State changed to IESG Evaluation from Waiting for Writeup |
2013-09-05
|
13 | Richard Barnes | Ballot approval text was generated |
2013-09-03
|
13 | (System) | State changed to Waiting for Writeup from In Last Call |
2013-08-27
|
13 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2013-08-27
|
13 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mediactrl-call-flows-13, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mediactrl-call-flows-13, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication. If this assessment is not accurate, please respond as soon as possible. |
2013-08-25
|
13 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. |
2013-08-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2013-08-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2013-08-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sam Hartman |
2013-08-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sam Hartman |
2013-08-20
|
13 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2013-08-20
|
13 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Media Control Channel Framework (CFW) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Media Control Channel Framework (CFW) Call Flow Examples) to Informational RFC The IESG has received a request from the Media Server Control WG (mediactrl) to consider the following document: - 'Media Control Channel Framework (CFW) Call Flow Examples' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-08-20
|
13 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-08-20
|
13 | Richard Barnes | Last call was requested |
2013-08-20
|
13 | Richard Barnes | Ballot approval text was generated |
2013-08-20
|
13 | Richard Barnes | State changed to Last Call Requested from Publication Requested |
2013-08-20
|
13 | Richard Barnes | Last call announcement was generated |
2013-08-20
|
13 | Richard Barnes | Ballot writeup was changed |
2013-08-20
|
13 | Richard Barnes | Ballot writeup was generated |
2013-07-17
|
13 | Amy Vezza | Document: Media Control Channel Framework (CFW) Call Flow Examples draft-ietf-mediactrl-call-flows-13 (1) What type of RFC is being requested (BCP, Proposed … Document: Media Control Channel Framework (CFW) Call Flow Examples draft-ietf-mediactrl-call-flows-13 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is the proper type, as the document doesn't define any new protocol/framework/architecture, but rather shows examples of the usage of existing protocols (especially RFCs 5239, 5567, 6230, 6231, 6505, 6917, i.e., the "media control" protocols) by means of state and sequence diagrams and message contents. The "Informational" status is indicated on the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document presents a series of MEDIACTRL-related call flows, presenting client/server state diagrams, message sequence diagrams, and message contents. It is a reference for the whole MEDIACTRL specification for implementers and protocol researchers alike, and all the flows are modeled from an implementation of the framework and its packages. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Several participants in the WG have advocated a call flows document. The advocates included Jon Peterson, who was the AD at the time the Mediactrl WG was chartered. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Lorenzo Miniero reports that interoperability tests were carried out at IETF73 (Minneapolis, Nov 2008) with implementations from HP (OCMP) and Dialogic testing scenarios illustrated by this document. The minutes report other companies that were planning an implementation at the time: "Stephan notes that implementation is be planned on Broadsoft for the spring. Alan notes that Ditech is also planning an implementation." (http://www.ietf.org/proceedings/73/minutes/mediactrl.htm) As an examples document, the document does not specify any protocol. All the contained examples were produced by running the scenarios using an existing implementation of the MEDIACTRL specification by the authors themselves. A thorough review was done by Dale Worley, who helped tackle some relevant inconsistencies in the presented scenarios. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Dale Worley. The Responsible Area Director is Richard Barnes. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd (Dale Worley) reviewed the document. The Shepherd identified a number of possible improvements to the document, including: adding definitions to the glossary for the benefit of people not familiar with the Media Control effort, discussing the additional configuration needs to obtain benefit from "IUMM mode" operation, removing from the examples the draft-boulton-mmusic-sdp-control-package-attribute extension (which was used in the implementation but has not progressed to standardization), and clarifying definition of the "gain" parameter. All of these issues were completely resolved. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Document Shepherd is satisfied with the review; the document should be easily comprehensible to a first-time reader of the relevant RFCs, and useful to any implementer of the RFCs. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. As there's no new protocol being specified, there is no need for specialized review: the specification RFCs (framework, packages, MRB) all have been through those processes, and the call flows document just applies what those documents specify. The XML message contents themselves have been automatically validated against the respective schemas. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no concerns regarding technical content. The English usage may need some cleaning up, as all the authors are non-native English speakers, but the Shepherd believes those needs are within the capabilities of the RFC Editor. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, all four authors have confirmed compliance with BCPs 78 and 79. Of course, these confirmations are for any IPR that is revealed draft-ietf-mediactrl-call-flows itself, and not for revelations in the documents that it references (especially RFCs 6230, 6231, 6505, 6917, and 5239), which define the protocols which are illustrated in this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None have been filed referencing this document. Regarding the RFCs which could be considered to be illustrated by the contents of draft-ietf-mediactrl-call-flows, that is, RFCs 6230, 6231, 6505, 6917, and 5239, there are IPR disclosures filed regarding RFC 6917. These disclosures have been well-known to the WG for several years. There is another draft, draft-boulton-mediactrl-mrb-location-function, on related subject matter, regarding which an IPR disclosure has been made. This disclosure has been well-known to the WG for several years. There is an expired draft, draft-sisalem-mediactrl-mrbctrl, on related subject matter, regarding which an IPR disclosure has been made. A chair (Eric Burger) has contacted the claimant (Tekelec), and Tekelec has declined to file an IPR disclosure on this patent regarding RFC 6917 (or regarding this document). This disclosure has been well-known to the WG for several years. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Several active participants in the WG have advocated the addition of such a call flows document to the milestones, and no one was opposed to it. The only concern was expressed by one of the WG chairs who feared protocol implementers would make use of the call flows document rather than the standards as the basis of an implementation, and thus the document was reviewed to ensure it contained no usages which are not the current best practices. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) None that the chairs or Shepherd are aware of. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The warnings found by the ID-Nits tool are: 1. == Missing Reference: 'AS1' is mentioned on line 7071, but not defined This is due to a descriptive phrase "join UAC&conf[AS1])" in which "conf[...]" is syntax, not a reference. 2. -- Found something which looks like a code comment This warning points to the uses of the XML element , which are correct relative to the relevant XML schema. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document specifies no new protocol or extension, so such a review was not needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are RFCs. (In the -12 version, there was a reference to an individual draft (draft-boulton-mmusic-sdp-control-package-attribute) whose progress toward standardization is currently unclear. The reference (and the use of the attribute which it specifies) were removed in the latest version (-13) of the document.) (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (In the -12 version, there were two normative references that are not standards track: RFC2606 (Reserved Top Level DNS Names) is a BCP, and RFC3725 (BCPs for Third Party Call Control (3pcc) in SIP) is a BCP. Both were changed to informative references in the latest (-13) version of the document.) (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, this document is just informational. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document specifies no new protocol or extension, so there is no IANA Considerations section. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document specifies no new protocol or extension, so there is no IANA Considerations section. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. According to the authors, all of the examples come from a real implementation (with the use of the draft-boulton-mmusic-sdp-control-package-attribute extension removed). In addition, all XML in the examples has been validated using a tool the authors themselves wrote for the purpose, which extracts XML content from the draft and validates it using the related XSD schema from the original specifications. |
2013-07-17
|
13 | Amy Vezza | Intended Status changed to Informational |
2013-07-17
|
13 | Amy Vezza | IESG process started in state Publication Requested |
2013-07-17
|
13 | Amy Vezza | Document shepherd changed to Dale R. Worley |
2013-07-17
|
13 | Richard Barnes | Changed document writeup |
2013-05-23
|
13 | Lorenzo Miniero | New version available: draft-ietf-mediactrl-call-flows-13.txt |
2013-04-22
|
12 | Lorenzo Miniero | New version available: draft-ietf-mediactrl-call-flows-12.txt |
2013-04-13
|
11 | Lorenzo Miniero | New version available: draft-ietf-mediactrl-call-flows-11.txt |
2012-11-27
|
10 | Lorenzo Miniero | New version available: draft-ietf-mediactrl-call-flows-10.txt |
2012-07-11
|
09 | Lorenzo Miniero | New version available: draft-ietf-mediactrl-call-flows-09.txt |
2012-01-09
|
08 | (System) | New version available: draft-ietf-mediactrl-call-flows-08.txt |
2011-07-11
|
07 | (System) | New version available: draft-ietf-mediactrl-call-flows-07.txt |
2011-03-14
|
06 | (System) | New version available: draft-ietf-mediactrl-call-flows-06.txt |
2010-10-14
|
05 | (System) | New version available: draft-ietf-mediactrl-call-flows-05.txt |
2010-05-17
|
04 | (System) | New version available: draft-ietf-mediactrl-call-flows-04.txt |
2010-02-10
|
03 | (System) | New version available: draft-ietf-mediactrl-call-flows-03.txt |
2009-10-26
|
02 | (System) | New version available: draft-ietf-mediactrl-call-flows-02.txt |
2009-07-13
|
01 | (System) | New version available: draft-ietf-mediactrl-call-flows-01.txt |
2009-03-04
|
00 | (System) | New version available: draft-ietf-mediactrl-call-flows-00.txt |