Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt
Harald Alvestrand <harald@alvestrand.no> Wed, 17 August 2011 09:41 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9C621F8AF9 for <rtcweb@ietfa.amsl.com>; Wed, 17 Aug 2011 02:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.34
X-Spam-Level:
X-Spam-Status: No, score=-101.34 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gSbhBi8Mmhg for <rtcweb@ietfa.amsl.com>; Wed, 17 Aug 2011 02:41:38 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2213721F8ACE for <rtcweb@ietf.org>; Wed, 17 Aug 2011 02:41:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6523039E0F5; Wed, 17 Aug 2011 11:41:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE0uRRcKPi+x; Wed, 17 Aug 2011 11:41:09 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [74.125.118.2]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 46FFF39E082; Wed, 17 Aug 2011 11:41:09 +0200 (CEST)
Message-ID: <4E4B8CFD.20906@alvestrand.no>
Date: Wed, 17 Aug 2011 11:42:21 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
References: <4E43BDB3.8000504@alvestrand.no> <1D062974A4845E4D8A343C65380492020625F795@XMB-BGL-414.cisco.com> <4E45282D.3000306@alvestrand.no> <1D062974A4845E4D8A343C65380492020625F7A6@XMB-BGL-414.cisco.com> <4E453FA5.8080702@alvestrand.no> <1D062974A4845E4D8A343C65380492020625FDC5@XMB-BGL-414.cisco.com>
In-Reply-To: <1D062974A4845E4D8A343C65380492020625FDC5@XMB-BGL-414.cisco.com>
Content-Type: multipart/alternative; boundary="------------030601080207020605080509"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 09:41:39 -0000
On 08/17/11 11:27, Muthu Arul Mozhi Perumal (mperumal) wrote: > > |I think it should be up to the offer generator whether > > |he adds "a=rtcp-mux" to the first section or not. > > Since the goal is to minimize the number of transport connections I > think we should put something stronger to encourage the offerer and > answerer to support RTCP multiplexing. At the minimum, a normative > statement recommending the use of RTCP multiplexing with this grouping > semantics would go a long way (symmetric RTP for e.g is a > recommendation, but virtually all implementations support it). > I agree that this is critical in the RTCWEB context. It may not be critical for all contexts. I think that should be a matter the (not yet existing) draft referenced here should say: 5. Data framing and securing SRTP [RFC3550] is used for transport of all real-time media. The detailed considerations for usage of functions from RTP and SRTP, as well as for non-media real-time data, are given in <WORKING GROUP DRAFT "MEDIA TRANSPORTS">. (this is from the -overview document) > > |Do we need to state that if the first section has it, all > > |the other sections have to have it, or can we live with a > > |mixture? > > If the first section has it, it can be applied to all other section > within that group, so it shouldn't matter whether the reset of the > sections have it or not. A mixture doesn't seem would serve any purpose. > When TOGETHER is applied, the other sections' values doesn't matter at all. When TOGETHER does NOT apply (fallback), it may matter. I don't see any purpose with a mixture either. But we'll see what further review brings. > > Muthu > > *From:*Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Friday, August 12, 2011 8:29 PM > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt > > On 08/12/11 16:12, Muthu Arul Mozhi Perumal (mperumal) wrote: > > |In general, I think we should keep extensions as orthogonal > > |as possible, so the normative language here should just say > > |"establish RTCP sessions normally for the first section, and > > |don't do it for other sections". > > Looks good to me. Should it also say "Within a TOGETHER group it is > RECOMMENDED to multiplex RTCP on the same RTP port from the first > section" or something stronger? > > I think it should be up to the offer generator whether he adds > "a=rtcp-mux" to the first section or not. > Do we need to state that if the first section has it, all the other > sections have to have it, or can we live with a mixture? > > Muthu > > *From:*Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Friday, August 12, 2011 6:49 PM > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* rtcweb@ietf.org <mailto:rtcweb@ietf.org> > *Subject:* Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt > > On 08/12/2011 03:09 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: > > A few comments: > > 1) Section 4 has this: > > If the responder understands the semantics of the TOGETHER extension, > > the parameters of the first section MUST be used to establish the RTP > > session, and the parameters for the other sections MUST be ignored. > > I think it needs to be: > > If the responder understands the semantics of the TOGETHER extension, > > the parameters of the first section MUST be used to establish the RTP > > and RCP session, and the parameters for the other sections MUST be > > ignored. > > Good point. Will fix. Normally, I think RTCWEB apps will use RTCP port > multiplexing (RFC 5761), so I did not think of it. > In general, I think we should keep extensions as orthogonal as > possible, so the normative language here should just say "establish > RTCP sessions normally for the first section, and don't do it for > other sections". > > 2) When the RTCP port is not the next higher (odd) port number > following the RTP port described in the m-line, the "a=rtcp" attribute > (defined in RFC-3605) is used to signal it, as in: > > m=audio 49170 RTP/AVP 0 > > a=rtcp:53020 IN IP4 126.16.64.4 > > With the grouping semantics described in the draft, it seems this RTCP > port should be taken only from the first section. So, this could be > could be added to section 4. > > 3) RTCP could be multiplexed with RTP on a single port and signaled > using the "a=rtcp-mux" attribute (defined in RFC 5761). When it is > used together with the grouping semantics described in the draft, it > seems all RTCP sessions of that group need to be multiplexed on the > RTP port from the first section. > > There should be only one RTCP session established for all the TOGETHER > m= lines, yes. > > Muthu > > *From:*rtcweb-bounces@ietf.org <mailto:rtcweb-bounces@ietf.org> > [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Harald Alvestrand > *Sent:* Thursday, August 11, 2011 5:02 PM > *To:* rtcweb@ietf.org <mailto:rtcweb@ietf.org> > *Subject:* [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt > > I have taken some of the information I learned from the discussions in > Quebec City about the issues of putting video and audio into the same > RTP session and created a draft from them outlining a solution to the > problem of signalling this configuration using SDP. > > Comments welcome, including the recommended context for processing the > document; in a few days I'll send the same note to AVTCORE and/or MMUSIC. > > Harald > > -------- Original Message -------- > > *Subject: * > > > > I-D Action: draft-alvestrand-one-rtp-00.txt > > *Date: * > > > > Thu, 11 Aug 2011 04:28:09 -0700 > > *From: * > > > > internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> > > *Reply-To: * > > > > internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> > > *To: * > > > > i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : SDP Grouping for Single RTP Sessions > Author(s) : Harald Tveit Alvestrand > Filename : draft-alvestrand-one-rtp-00.txt > Pages : 8 > Date : 2011-08-11 > > This document describes an extension to the Session Description > Protocol (SDP) to describe RTP sessions where media of multiple top > level types, for example audio and video, are carried in the same RTP > session. > > This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for > consideration. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-alvestrand-one-rtp-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-alvestrand-one-rtp-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org> > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories:http://www.ietf.org/shadow.html > orftp://ftp.ietf.org/ietf/1shadow-sites.txt > >
- [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rt… Harald Alvestrand
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Paul Kyzivat
- Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp… Ross Finlayson
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp… Harald Alvestrand
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Harald Alvestrand
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Paul Kyzivat
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Harald Alvestrand
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp… Paul Kyzivat
- [rtcweb] Combining attributes (Re: Fwd: I-D Actio… Harald Alvestrand
- Re: [rtcweb] draft-alvestrand-one-rtp-00.txt ICE … Paul Kyzivat
- Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp… Randell Jesup
- Re: [rtcweb] draft-alvestrand-one-rtp-00.txt ICE … Randell Jesup
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Justin Uberti
- Re: [rtcweb] draft-alvestrand-one-rtp-00.txt ICE … Paul Kyzivat
- [rtcweb] draft-alvestrand-one-rtp-00.txt and inte… Christer Holmberg
- Re: [rtcweb] draft-alvestrand-one-rtp-00.txt and … Christer Holmberg
- Re: [rtcweb] draft-alvestrand-one-rtp-00.txt and … Harald Alvestrand
- Re: [rtcweb] draft-alvestrand-one-rtp-00.txt and … Christer Holmberg
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp… Harald Alvestrand
- Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp… Randell Jesup
- Re: [rtcweb] I-D Action: draft-alvestrand-one-rtp… Harald Alvestrand
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Harald Alvestrand
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Harald Alvestrand
- Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-on… Colin Perkins