Re: [MEDIACTRL] WGLC: Call Flows

Lorenzo Miniero <lorenzo@meetecho.com> Mon, 03 December 2012 23:00 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DDA21F8977 for <mediactrl@ietfa.amsl.com>; Mon, 3 Dec 2012 15:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.581
X-Spam-Level: *
X-Spam-Status: No, score=1.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_TIME=2.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqLOiL10vJDP for <mediactrl@ietfa.amsl.com>; Mon, 3 Dec 2012 15:00:41 -0800 (PST)
Received: from smtpdg3.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id 86A1421F896E for <mediactrl@ietf.org>; Mon, 3 Dec 2012 15:00:40 -0800 (PST)
Received: from rainpc ([79.30.35.16]) by smtpcmd01.ad.aruba.it with bizsmtp id XB0c1k00S0LtQiv01B0cgR; Tue, 04 Dec 2012 00:00:38 +0100
Date: Tue, 4 Dec 2012 00:00:35 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <20121204000035.796e04b4@rainpc>
In-Reply-To: <50BD0C95.10401@nostrum.com>
References: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> <50BD0C95.10401@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] WGLC: Call Flows
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Mon, 03 Dec 2012 23:00:41 -0000

On Mon, 03 Dec 2012 14:33:25 -0600
Robert Sparks <rjsparks@nostrum.com> 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
> > MEDIACTRL@ietf.org
> > 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