From stewe@stewe.org Fri Apr 1 03:45:26 2011 Return-Path: X-Original-To: rai@core3.amsl.com Delivered-To: rai@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554533A67F5; Fri, 1 Apr 2011 03:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q+n+EXsCBEM; Fri, 1 Apr 2011 03:45:25 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 0AFF73A67D3; Fri, 1 Apr 2011 03:45:24 -0700 (PDT) Received: from [130.129.83.67] (unverified [130.129.83.67]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4736-1743317 for multiple; Fri, 01 Apr 2011 12:47:03 +0200 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 01 Apr 2011 12:46:58 +0200 From: Stephan Wenger To: , , , Message-ID: Thread-Topic: Incoming liaison statement from MPEG Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384506822_481335" X-Originating-IP: 130.129.83.67 X-Authenticated-User: stewe@stewe.org Subject: [RAI] Incoming liaison statement from MPEG X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:45:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384506822_481335 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, We have received a liaison statement from the MPEG meeting that took place last week. No action is requested from us. They have an initial draft for the profiles of their HTTP streaming project known as "DASH", which is in DIS state. In short, my reading is that they are currently considering one "simple" and one more complex profile for each MPEG-2 TS and ISO file format based mux structure, for a total of four profiles. The statement should appear on the IETF statement tracker shortly, but if you need a copy urgently, please send me a private email and I will forward. Thanks, Stephan --B_3384506822_481335 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

Hi all,

We have re= ceived a liaison statement from the MPEG meeting that took place last week. = No action is requested from us.

They have an initial draft f= or the profiles of their HTTP streaming project known as "DASH", which is in= DIS state. In short, my reading is that they are currently considerin= g one "simple" and one more complex profile for each MPEG-2 TS and ISO file = format based mux structure, for a total of four profiles. The statemen= t should appear on the IETF statement tracker shortly, but if you need a cop= y urgently, please send me a private email and I will forward.

Tha= nks,

Stephan

--B_3384506822_481335-- From rjsparks@nostrum.com Fri Apr 15 08:47:15 2011 Return-Path: X-Original-To: rai@ietfc.amsl.com Delivered-To: rai@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9D680E08FB for ; Fri, 15 Apr 2011 08:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJDHMUG6uUgd for ; Fri, 15 Apr 2011 08:47:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfc.amsl.com (Postfix) with ESMTP id 14B52E08F9 for ; Fri, 15 Apr 2011 08:47:09 -0700 (PDT) Received: from 132-177-252-250.ip.sipit.net ([132.177.252.250]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p3FFkVsL057391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 Apr 2011 10:47:08 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 10:47:08 -0500 Message-Id: <2ADFB5A9-9D27-462E-A754-951D48DDBF42@nostrum.com> To: rai@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 132.177.252.250 is authenticated by a trusted mechanism) Subject: [RAI] SIPit 28 summary X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:47:15 -0000 Also available at RjS -------- SIPit 28 was hosted by Digium in Huntsville, Alabama, USA the week of Arpil 11-15, 2010. There were 54 attendees from 19 companies visiting from 10 countries. We had 40 distinct implementations.=20 The roles represented (some implementations act in more than one role) 34 endpoints 6 proxy/registrars/b2bua/sbcs 1 dedicated event server Implementations using each transport for SIP messages: UDP 98%=20 TCP 95% TLS 68% server-auth, 50% mutual-auth SCTP 10% DTLS 0% 68% of the implementations present supported IPv6. There was one RFC4474 Identity implementation present. For DNS we had support for: Full RFC3263 : 53%=20 SRV only : 33% A records only : 15% no DNS support : 0% Support for various items in the endpoints:=20 76% replaces 38% 5389stun 26% turn 24% 3489stun 24% ice 21% sip/stun multiplexing 21% outbound=20 21% gruu 18% path 18% join 18% diversion 6% history-info (there were no implementations of 4244bis) 3% service-route 3% sigcomp Support for various items in the proxy/registrars: 50% path 50% outbound 33% sip/stun multiplexing 20% diversion 18% gruu 17% history-info 17% service-route The endpoints and B2BUAs implemented these methods: 100% INVITE, CANCEL, ACK, BYE=20 94% REGISTER 91% OPTIONS 91% REFER 82% NOTIFY=20 82% INFO 79% UPDATE 71% SUBSCRIBE 68% PRACK=20 47% PUBLISH=20 29% MESSAGE 94% of the implementations sent RTP from the port advertised for = reception (symmetric-rtp). One of the implementations required the other party to use = symmetric-rtp. 88% of the UAs present both sent RTCP and paid attention to RTCP they = received. 56% of the endpoints present supported SRTP using sdes. There was one dtls-srtp implementations at this SIPit. 67% of the endpoints supported multipart/MIME. There were no implementations present with S/MIME support.=20 48% of the implementations present followed RFC6026 (corrections to the = INVITE transaction) 68% followed RFC4320 (corrections to the non-INVITE transaction) There were 5 SIP Event Server implementations (not counting endpoints = that support events only for refer). There were 9 SIP Event Client implementations (not counting endpoints = that support events only for refer). These event packages were supported: Server Client 2 3 presence 1 0 presence.winfo 1 6 message-summary 2 5 dialog 0 2 reg 2 1 conference 1 0 xcap-diff 0 1 kpml These packages were supported with the eventlist extension: Server Client 1 0 presence Five of the proxies present still rely only on max-forwards.=20 There was one implementation of fork-loop-fix, but no implementations of = max-breadth. Multiparty tests=20 (Thanks to Eoin McLeod for contributing notes for several tests) The Forking test was very well attended. We had the majority of the = participants at the multiparty table. Many teams took away good new information from = watching their implementation react to multiple merges and to Via stacks with = transports switching between IPv4 and IPv6. Forcing multiple 200 Oks was more = difficult than usual given the network equipment at hand. We've created a set of = standing automated tests that will allow endpoints and proxies to test that scenario at = their leisure. The TLS multiparty leveraged DNS to reduce configuration churn. We = ensured a full mesh of connections between participating elements. There were some = issues uncovered with the values used in Route/Record-Route not matching the configured = certificates at an element. We brainstormed a configuration for the next event that = will efficiently expose whether elements are correctly opening a new connection (rather = than reusing an existing connection) when a new request with a resource belonging to an = authority not matching what had been authenticated on the existing connection arrived. The SRTP tests showed a high level of interoperability (all with SDES = keying), including hold/resume and transfer scenarios. There was a successful = test of a call with media running long enough to increment the ROC, followed by a hold/resume. Several participants were trying variants of "best-effort/opportunistic" encryption with lower levels of success. = These elements tested providing offers with both RTP/AVP and RTP/SAVP = media-lines describing the same logical media channel, and with multiple RTP/AVP = media lines decorated with different crypto attributes. The STUN/TURN/ICE tests had very high levels of interoperability. The = test scenario involved elements in two natted networks sharing the same = address space and elements in the public address space (including a separate TURN = server for each of the private network islands). We had a mix of elements that supported = relay=20 allocation and elements that presented only host/reflexive candidates. A few elements assumed that all of the m-lines in an offer had to = present ICE=20 candidates. SDP with a mix of ICE enabled m-lines and m-lines without = candidates caused ICE failures. The Outbound test showed several successful flows being created and = maintained. A mesh of edge-proxies and proxy/registrars were set up and endpoints = established flows through several combinations. There was good UA support for the = Flow-Timer, but there were implementations present that didn't randomize the = keepalive value. There was not much testing of recovery from failed flows at this event - = we'll focus on that at SIPit 29. We held a long multiparty session focusing on exchanging video with = constrained bandwidth or impaired (latent or lossy) networks. There was a high level = of basic interoperability and reasonable reaction to mid-call shifts in = network conditions, but all parties involved came away with changes they wanted = to make in their implementations. The Spiral test presented requests to the participating UAs containing a = mix of UDP, TCP, and TLS over IPv4 and IPv6 values in large Via and = Record-Route stacks. Correct operation of subsequent in-dialog requests in both directions = was tested, discovering a few implementation problems, and some invalid assumptions = about how dialog-stateful proxies might need to behave, but most scenarios worked = well. We followed the usual Spiral test with a "fuzz-ball" test utilizing DNS SRV = to randomly distribute the propagation of messages through all of the proxies = present, hopping off to the UAs with a low probability, resulting in an easy-to-configure = test that exercised a full-mesh of connections between proxies and presented the = UAs with very diverse (and large) Via and Record-Route header field values. We exercised the RFC5393 proxy-doom scenario, again leveraging the SRV = load-leveling capabilities to simplify configuration. We had messages popping out to = the UAs from=20 each level of the tree, giving them a very large-scale merge test.