Re: [MEDIACTRL] Call Flows Document

[[e-mail]]

That's great news! Someone finally read our draft! Thanks Roni for  
your comments. We'll discuss them and fix the potential nits you  
identified.

Cheers,

Simon

Quoting "Even, Roni" <[e-mail]>:

> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Mary Barnes
> Sent: Thursday, July 31, 2008 12:00 PM
> To: Eric Burger; [e-mail]
> Subject: Re: [MEDIACTRL] Call Flows Document
>
>
>
> Thanks for the detailed (and accurate) summary of this issue. My
> responses are below [MB].
>
>
>
> Mary.
>
>
>
> ________________________________
>
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Eric Burger
> Sent: Wednesday, July 30, 2008 12:48 PM
> To: [e-mail]
> 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.
>
>



-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: [phone] -- Fax: [phone]
                 e-mail: [e-mail]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/
_______________________________________________
MEDIACTRL mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl