Re: [MEDIACTRL] WGLC: Call Flows

Lorenzo Miniero <lorenzo@meetecho.com> Mon, 03 December 2012 23:13 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 8272B21F8968 for <mediactrl@ietfa.amsl.com>; Mon, 3 Dec 2012 15:13:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.734
X-Spam-Level: *
X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, MANGLED_TIME=2.3, RDNS_NONE=0.1]
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 AxsjLKru24gK for <mediactrl@ietfa.amsl.com>; Mon, 3 Dec 2012 15:13:47 -0800 (PST)
Received: from smtpdg7.aruba.it (unknown [62.149.158.225]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0421F86F3 for <mediactrl@ietf.org>; Mon, 3 Dec 2012 15:13:42 -0800 (PST)
Received: from rainpc ([79.30.35.16]) by smtpcmd03.ad.aruba.it with bizsmtp id XBDg1k00V0LtQiv01BDgDq; Tue, 04 Dec 2012 00:13:41 +0100
Date: Tue, 04 Dec 2012 00:13:39 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <20121204001339.0beadeb7@rainpc>
In-Reply-To: <50BD2FE8.2080907@nostrum.com>
References: <32EF9DF1-B5EB-4AFE-9080-91BAC1E6559C@standardstrack.com> <50BD0C95.10401@nostrum.com> <20121204000035.796e04b4@rainpc> <50BD2FE8.2080907@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:13:48 -0000

Replying inline,


On Mon, 03 Dec 2012 17:04:08 -0600
Robert Sparks <rjsparks@nostrum.com> wrote:

> inline -
> 
> On 12/3/12 5:00 PM, Lorenzo Miniero wrote:
> > 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.
> That helps, thanks. Reviews should look at the places those names occur 
> and make sure the right ones landed in the right places.
> >
> >
> >> 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.
> That would be it. The type application/msc-ivr+xml doesn't require the 
> 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
> >
> >
> >> 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