Subject: [MEDIACTRL] WGLC: Call Flows

From: Eric Burger <[email-masked]>
Date: Mon, 3 Dec 2012 09:45:27 -0500

We are almost finished! One last document to go, the Media Control Channel Framework (CFW) Call Flow Examples.  You can pickup a copy here:
https://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows

Please review CLOSELY, as no matter how many times we tell implementors to read the base specifications and that this document is simply a non-normtive example,  implementors will blindly copy from this document and not read the base documents. It MUST be as accurate as possible.

Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 03 Dec 2012 14:33:25 -0600

> Because of the importance of getting this right, the Work Group Last Call will run until 21 December 2012.
Yes, please. If you are going to dive deep on any one particular aspect 
of this review, please let the list know so
we spread the effort around. There's a _lot_ to review here.

Lorenzo - I really appreciate that the SIP was generated by real 
implementations - did you set things up where they were actually using 
example.com and example.net or did you edit the captured messages to say 
that after the fact?

One question about some of the CFW examples. We have this section:

2.  Conventions

    Note that due to RFC formatting conventions, this document often
    splits SIP/SDP and CFW across lines whose content would exceed 72
    characters.  A backslash character marks where this line folding has
    taken place.  This backslash and its trailing CRLF and whitespace
    would not appear in the actual protocol contents.  Besides, also note
    that the indentation of the XML content is only provided for
    readability: actual messages will follow strict XML syntax, which
    allows for, but does not require, indentation.  Due to the same 72
    characters limitation, this document also sometimes splits the
    content of XML elements across lines: please beware that, when this
    happens, no whitespace is actually meant to be neither at the
    beginning nor at the end of the element content.

Should it go on to say that the Content-Lengths in the examples were
calculated _before_ formatting the example for publication in the RFC?
I can't, for example, make the content-length in this example make sense:

D1. AS <- MS (CFW CONTROL event, dtmfnotify)
--------------------------------------------
    CFW 361840da0581 CONTROL
    Control-Package: msc-ivr/1.0
    Content-Type: application/msc-ivr+xml
    Content-Length: 179

    <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
       <event dialogid="3e936e0">
          <dtmfnotify matchmode="control" dtmf="6"
                      timestamp="2008-12-16T12:58:36Z"/>
       </event>
    </mscivr>

Even if I rip out _all_ the whitespace outside of the tags and assume
a single LF instead of a CRLF, I get 180?

0000000   <   m   s   c   i   v   r       v   e   r   s   i   o n   =
0000010   "   1   .   0   "       x   m   l   n   s   =   "   u r   n
0000020   :   i   e   t   f   :   p   a   r   a   m   s   :   x m   l
0000030   :   n   s   :   m   s   c   -   i   v   r   "   > <   e   v
0000040   e   n   t       d   i   a   l   o   g   i   d   =   " 3   e
0000050   9   3   6   e   0   "   >   <   d   t   m   f   n o   t   i
0000060   f   y       m   a   t   c   h   m   o   d   e   =   " c   o
0000070   n   t   r   o   l   "       d   t   m   f   =   "   6 "
0000080   t   i   m   e   s   t   a   m   p   =   "   2   0   0 8   -
0000090   1   2   -   1   6   T   1   2   :   5   8   :   3   6 Z   "
00000a0   /   >   <   /   e   v   e   n   t   >   < /   m   s   c   i
00000b0   v   r   >  \n

RjS

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 4 Dec 2012 00:00:35 +0100

On Mon, 03 Dec 2012 14:33:25 -0600

> example.com and example.net or did you edit the captured messages to say 

Those messages were edited, as they originally involved the local environment we deployed our testbed in. I tried to make sure the content lengths were properly adjusted where necessary, though.

> D1. AS <- MS (CFW CONTROL event, dtmfnotify)

Just as with SIP, we tried to keep the content length consistent when the payload was edited (e.g., in small changes in the protocol that didn't really need a new dump). With respect to the example you reported, the payload in our prototype does not include the trailing LF either, but just the XML content, so I guess that's where the extra character in the count comes from.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Robert Sparks <[email-masked]>
Date: Mon, 03 Dec 2012 17:04:08 -0600

inline -

> Those messages were edited, as they originally involved the local environment we deployed our testbed in. I tried to make sure the content lengths were properly adjusted where necessary, though.
That helps, thanks. Reviews should look at the places those names occur 
and make sure the right ones landed in the right places.
> Just as with SIP, we tried to keep the content length consistent when the payload was edited (e.g., in small changes in the protocol that didn't really need a new dump). With respect to the example…
That would be it. The type application/msc-ivr+xml doesn't require the 
trailing newline does it?

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 4 Dec 2012 00:13:39 +0100

Replying inline,

On Mon, 03 Dec 2012 17:04:08 -0600

> trailing newline does it?

I just checked and it looks like it doesn't, and I guess the same applies to the mixer spec as well.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Eric Burger <[email-masked]>
Date: Tue, 4 Dec 2012 07:16:02 -0800

This is why we need to look VERY closely at this document. It will uncover assumptions that were left unstated.  What we miss will be considered gospel, so please look long and hard!