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
- [MEDIACTRL] WGLC: Call Flows Eric Burger
- Re: [MEDIACTRL] WGLC: Call Flows Robert Sparks
- Re: [MEDIACTRL] WGLC: Call Flows Lorenzo Miniero
- Re: [MEDIACTRL] WGLC: Call Flows Robert Sparks
- Re: [MEDIACTRL] WGLC: Call Flows Lorenzo Miniero
- Re: [MEDIACTRL] WGLC: Call Flows Eric Burger