Subject: [MEDIACTRL] Call Flows Document

From: Eric Burger <[email-masked]>
Date: Wed, 30 Jul 2008 18:47:31 +0100

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.

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)
    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)
    c. A test suite document, describing how to achieve interoperability
       (see http://www.msforum.org/techinfo/approved/MSF-IA-SIP.015-FINAL.pdf)
    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?
    b. Is it OK for them to be Individual documents, for now.

Please RSVP with your views on the above questions.

Thanks.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 30 Jul 2008 13:36:36 -0500

Yeah, Eric and I talk, from time to time...

Just to add my concern as one half of the working group chairship, what I really want to see happen is that such a document is produced, but that we do not adopt it so quickly that having the six-or-so reviewers who volunteered focused on this document will not interfere with the currently chartered deliverables.

It would be most helpful if we got through the re-WGLCs and WGLCs that we talked about today, REALLY FAST and with good quality, so we will have mostly-cleared decks really soon and can focus on this excellent document, and on the currently-chartered Media Resource Broker.

So please keep an eye out for WGLC e-mail from myself and from Eric, because our working group milestone list could be dramatically different by the end of September if we really focus - or dramatically the same by the end of 2008, if we just cycle once per IETF meeting.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Eric Burger 
  To: [email-masked] 
  Sent: Wednesday, July 30, 2008 12:47 PM
  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.

  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:

        how the protocol works (see draft-ietf-sipping-service-examples-15

  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?
     b. Is it OK for them to be Individual documents, for now.

  Thanks.

------------------------------------------------------------------------------

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 31 Jul 2008 10:50:47 +0200

Two points:
 
1)    If a document is produced, and no matter whether it is author
initiated or WG initiated, it should be subject to the same care and
review that the specifications receive. If we cannot give it that, we
stand a chance of having an inaccurate document with all the problems
listed. If the document is not going to get the WG care and review, then
we should not proceed with the document.
 
2)    In regard to Q1 on the type of document, I don't object to
producing any of these document (subject to the constraints above), but
I believe it is inappropriate to combine 1a) with 1b) or 1c). These are
two separate kinds of document and should be published separately. The
first would be expected to indicate the normal operation. Test and
interoperability documents even as flows are more likely to show the
abnormal cases.
 
regards
 
Keith

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Burger
	Sent: Wednesday, July 30, 2008 6:48 PM
	To: [email-masked]
	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.

	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.

	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)
	   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)
	   c. A test suite document, describing how to achieve
interoperability
	      (see
http://www.msforum.org/techinfo/approved/MSF-IA-SIP.015-FINAL.pdf)
	   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?
	   b. Is it OK for them to be Individual documents, for now.

	Thanks.

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 31 Jul 2008 04:00:25 -0500

Thanks for the detailed (and accurate) summary of this issue. My
responses are below [MB]. 
 
Mary.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Burger
Sent: Wednesday, July 30, 2008 12:48 PM
To: [email-masked]
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
group item. 

To recap:

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] 

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

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]

Thanks.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 31 Jul 2008 05:26:07 -0400

I agree that a document with illustrative/sample call flows should be 
distinct from any "torture test" or "interoperability spec".

And the illustrative call flows are of the greatest immediate interest, at 
least for me.

Janet

Computer Sciences Corporation 
Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042, 
USA
Registered in Nevada, USA No: C-489-59

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

"DRAGE, Keith \(Keith\)" <[email-masked]> 
Sent by: [email-masked]
07/31/2008 04:50 AM

To
"Eric Burger" <[email-masked]>, <[email-masked]>
cc

Subject
Re: [MEDIACTRL] Call Flows Document

Two points:

2)    In regard to Q1 on the type of document, I don't object to producing 
any of these document (subject to the constraints above), but I believe it 
is inappropriate to combine 1a) with 1b) or 1c). These are two separate 
kinds of document and should be published separately. The first would be 
expected to indicate the normal operation. Test and interoperability 
documents even as flows are more likely to show the abnormal cases.
 
regards
 
Keith

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:

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:

Thanks._______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 31 Jul 2008 12:45:42 +0300

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Mary Barnes
Sent: Thursday, July 31, 2008 12:00 PM
To: Eric Burger; [email-masked]
Subject: Re: [MEDIACTRL] Call Flows Document

Mary.

group item. 

To recap:

      specification at all.

      for an example) 

      (see

   e. All of a, b, and c

 

Thanks.

---

From: [email-masked]
Date: Thu, 31 Jul 2008 11:51:53 +0200

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

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

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

---

From: Dan York <[email-masked]>
Date: Thu, 31 Jul 2008 07:20:16 -0400

I'll agree with Keith on his two points here.  For all the reasons  
outlined by Eric, a call flows document needs to stay locked in sync  
with the specification so that it *is* an accurate representation of  
the specification.  If at some point in time we either revise the main  
MCCF specification, or extend/change it with other RFCs, we need to  
ensure that the Call Flows document is revised so that it reflects the  
current specification(s).

In my opinion, any document that helps implementors better understand  
*how* to implement our specifications is a good thing to have around.   
If our end goal is to have our protocols widely used and deployed,  
anything that helps guide implementors is good.  Call flows, sample  
implementations (such as that of the Univ. of Napoli team), "HOWTO"  
documents, etc., all are good to have.  It's similar to any vendor's  
product release... when the product is launched, there is usually  
accompanying training classes, presentations, etc. that teach/show how  
to use the new product.

Obviously, though, those "implementation aids" do have to accurately  
represent the current state of the specification and so in committing  
to create such a document, we are also implicitly committing to keep  
that document up-to-date.

My 2 cents,
Dan

On Jul 31, 2008, at 4:50 AM, DRAGE, Keith (Keith) wrote:

> review that the specifications receive. If we cannot give it that,  
> we stand a chance of having an inaccurate document with all the  
> problems listed. If the document is not going to get the WG care and  
> review, then we should not proceed with the document.
>
> producing any of these document (subject to the constraints above),  
> but I believe it is inappropriate to combine 1a) with 1b) or 1c).  
> These are two separate kinds of document and should be published  
> separately. The first would be expected to indicate the normal  
> operation. Test and interoperability documents even as flows are  
> more likely to show the abnormal cases.
>
> regards
>
> Keith
>
> From: [email-masked] [mailto:[email-masked]]  
> On Behalf Of Eric Burger
> adding <http://www.ietf.org/internet-drafts/draft-miniero-mediactrl-escs-02.txt 
> 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:
>

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 31 Jul 2008 08:11:08 -0400

Greetings,
 
I agree with Spencer that this should be a WG item, but not now, as to
focus cycles on the other documents. As the other documents, that would
feed into this document become more stable, we would make this a WG
item.
 
Whether a individual or WG item, it should get meeting time.
 
Common sense dictates, as many folks have stated, that the document
needs to be updated to be in-sync with the normative drafts.
 
Martin

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Burger
Sent: Wednesday, July 30, 2008 1:48 PM
To: [email-masked]
Subject: [MEDIACTRL] Call Flows Document

group item. 

To recap:

Thanks.

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 31 Jul 2008 17:31:26 +0300

Hi,

I did not volunteer to read the draft, but still think that before accepting a document as a WG item it must get some reviews that will be reflected on the list even if it just says "I read the draft and find it as a good start for call flows document"
 
Roni

> -----Original Message-----
> Behalf Of [email-masked]
> Sent: Thursday, July 31, 2008 12:52 PM
> To: [email-masked]
> On
> On
> wrong
> will

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 31 Jul 2008 19:38:11 +0200

Just to clarify, we've so far already tried to keep the call flows  
document synced with the mediactrl drafts as well as we could. Of  
course, when IETF meetings and the like are on their way, there are  
deadlines to abide by, and this applies to both normative documents  
and our work. This means that, if drafts are uploaded like one day  
before the deadline, we can't possibly update ours accordingly in  
time; at least not as long as we won't have ten or more engineers to  
whip and force to do the dirty work for us, which is unlikely to ever  
happen ;)

The next version of the draft will have the call flows updated with  
respect to the mixer draft too, which we already implemented anyway.

Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl