Re: [MEDIACTRL] WGLC: Call Flows

[Lorenzo Miniero <[e-mail]>]

On Mon, 03 Dec 2012 14:33:25 -0600
Robert Sparks <[e-mail]> wrote:

> On 12/3/12 8:45 AM, Eric Burger wrote:
> > 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.
> 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?
> 


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.


> 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
> 


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


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


-- 
Lorenzo Miniero, COB

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