Re: [MEDIACTRL] Call Flows Document
"Even, Roni" <roni.even@polycom.co.il> Thu, 31 July 2008 09:44 UTC
Return-Path: <mediactrl-bounces@ietf.org>
X-Original-To: mediactrl-archive@optimus.ietf.org
Delivered-To: ietfarch-mediactrl-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DB83A6C23; Thu, 31 Jul 2008 02:44:56 -0700 (PDT)
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90923A680A for <mediactrl@core3.amsl.com>; Thu, 31 Jul 2008 02:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhF8QrcEj8TW for <mediactrl@core3.amsl.com>; Thu, 31 Jul 2008 02:44:46 -0700 (PDT)
Received: from isrexch01.israel.polycom.com (fw.polycom.co.il [212.179.41.2]) by core3.amsl.com (Postfix) with ESMTP id 020223A6A60 for <mediactrl@ietf.org>; Thu, 31 Jul 2008 02:44:38 -0700 (PDT)
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 12:45:42 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C05D2B81E@IsrExch01.israel.polycom.com>
In-Reply-To: <F66D7286825402429571678A16C2F5EE04A52D84@zrc2hxm1.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-topic: [MEDIACTRL] Call Flows Document
Thread-index: AcjybGitjtyyt8O6QCeGiaIgL0PGzAAfAIKgAAGwzvA=
References: <41D05D54-443E-4A32-86F6-1728B51061A1@standardstrack.com> <F66D7286825402429571678A16C2F5EE04A52D84@zrc2hxm1.corp.nortel.com>
From: "Even, Roni" <roni.even@polycom.co.il>
To: Mary Barnes <mary.barnes@nortel.com>, Eric Burger <eburger@standardstrack.com>, mediactrl@ietf.org
Subject: Re: [MEDIACTRL] Call Flows Document
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: multipart/mixed; boundary="===============0652092404=="
Sender: mediactrl-bounces@ietf.org
Errors-To: mediactrl-bounces@ietf.org
Hi, I can accept Mary's comments. My humble input is that the current ecs document cannot serve as a starting point, it is not just a media control example flows document. I assume we want to have basic call flows examples yet the document does not supply simple examples but goes to a detailed analysis of the media control architecture based on the authors interpretation. The comments are partial and do not even address the syntax of the examples. I accept that other people will review the ecs draft before we can decide if this is a good start for a WG document. The abstract of the document says that this is not just call flows. "It aims at being a simple guide throughout the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a hopefully helpful base reference documentation for both implementors and protocol researchers." Section 4 is not relevant to call flows since it describes an implementation Even though the document claims to have simple call flows it goes to high details based on a specific implementation, the text is not describing the flow but gives interpretation of the normative text in the framework document Figure 6 and the text describes one way to establish 3pcc and not the media control flow. 3pcc is described in other RFCs and there is more than one way to do it. Echo test is not related to the media control call flows. The phone call scenario starts with a SIP 3pcc flow describing 3pcc and the whole example is not a typical AS-MS call flow. In figure 20 it shows the flow of the media control but missing the step where the UA using SIP connects to the MS. This is important since we have assumption that the Mediactrl JOIN arrives before the SIP invite Roni From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, July 31, 2008 12:00 PM To: Eric Burger; mediactrl@ietf.org Subject: Re: [MEDIACTRL] Call Flows Document Thanks for the detailed (and accurate) summary of this issue. My responses are below [MB]. Mary. ________________________________ From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On Behalf Of Eric Burger Sent: Wednesday, July 30, 2008 12:48 PM To: mediactrl@ietf.org Subject: [MEDIACTRL] Call Flows Document At the meeting today, we discussed at length the issues around adding <http://www.ietf.org/internet-drafts/draft-miniero-mediactrl-escs-02.txt >, "Media Control Channel Framework (CFW) Call Flow Examples" as a work group item. To recap: 1. Just about everyone stated it is extremely useful to have call flows. a. Important for us as protocol developers to debug the specification, e.g., "Oops - we forgot that message" b. Important for some developers with interpretation of the specifications c. Important for interoperability testing 2. Many people pointed out call flow documents have their drawbacks. a. Some people will code to the call flows and not to the specification. i. If the call flows are wrong, the developer will code the wrong thing. ii. Call flows cannot capture the nuances of the protocol, such as non-deterministic message order or legal, but not shown in a call flow, messages that pop up b. When people see a call flow document, they may not read the specification at all. c. When people see a Work Group *draft*, they may consider it to be a stable, authoritative reference. [MB] IMHO, there's not much we can do nor do we have much control over any of the above - it is what it is. I don't disagree at all that call flows cannot at all capture all the normative details of the protocol that must be implemented. However, for folks that are visual learners, the flows are an invaluable guide to work one's way through the specs. And, none of our specs are ever perfect and the flows can sometimes be a source of identifying those bugs (even after publication). [/MB] It would be safe to say that no matter what we decide here, there will be a call flows document. The questions to decide are: 1. What document(s) will we produce? Will we produce: a. A basic call flows document, illustrating some examples of how the protocol works (see draft-ietf-sipping-service-examples-15 for an example) [MB] IMHO, this is most important for now in developing in parallel with the protocol and is an invaluable reference for implementations. I also do not believe that even with the flows you will NOT get identical broken implementations from the flows as there are always gaps that must be filled in based on the normative details in the protocol spec. [/MB] b. A torture test document, illustrating examples of malformed messages or messages seriously out of order, that stacks must not barf on (see RFC 4475 for an example) [MB] I think it would be very difficult to produce this (and not necessarily useful) until after there's been some basic interop testing and folks can see what are the most common errors and perhaps add variations of such. [/MB] c. A test suite document, describing how to achieve interoperability (see http://www.msforum.org/techinfo/approved/MSF-IA-SIP.015-FINAL.pdf) <http://www.msforum.org/techinfo/approved/MSF-IA-SIP.015-FINAL.pdf> [MB] This seems to be something well beyond the completion of the protocol and maturity of implementations. And, maybe would be more of a SIPForum activity.[/MB] d. A plurality of a, b, or c e. All of a, b, and c Note all call flow documents are Informational (not Normative) by definition. 2. Will the work group produce these documents? No matter what, individuals from the work group will write the document(s), and people in the work group (many have already volunteered) will review the document(s). a. Do they need to be Work Group documents? [MB] I honestly can see no problems in making them WG documents and alot of positive reasons: folks pay more attention, the review is more rigorous (by all review teams AFAIK) and it acknowledges the work done by authors/editors. [/MB] b. Is it OK for them to be Individual documents, for now. [MB] In my view, as long as we get a milestone for 1a, then I'm not so concerned. I did speak to Roni after the meeting and I believe his concern over inconsistencies between the protocol and the current call flow document are valid and should be addressed and if it makes the WG more comfortable having this done prior to adopting as a WG document, that's okay. There is precedence in the past to adopt a document with an agreement to update per WG input and concerns. [/MB] Please RSVP with your views on the above questions. Thanks.
_______________________________________________ MEDIACTRL mailing list MEDIACTRL@ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl
- Re: [MEDIACTRL] Call Flows Document DRAGE, Keith (Keith)
- [MEDIACTRL] Call Flows Document Eric Burger
- Re: [MEDIACTRL] Call Flows Document Spencer Dawkins
- Re: [MEDIACTRL] Call Flows Document Mary Barnes
- Re: [MEDIACTRL] Call Flows Document Janet P Gunn
- Re: [MEDIACTRL] Call Flows Document Even, Roni
- Re: [MEDIACTRL] Call Flows Document spromano
- Re: [MEDIACTRL] Call Flows Document Dan York
- Re: [MEDIACTRL] Call Flows Document DOLLY, MARTIN C, ATTLABS
- Re: [MEDIACTRL] Call Flows Document Even, Roni
- Re: [MEDIACTRL] Call Flows Document Lorenzo Miniero