Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt
Harald Alvestrand <harald@alvestrand.no> Fri, 12 August 2011 14:58 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 38A9521F8745 for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 07:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.247
X-Spam-Level:
X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=-0.249, 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 WEmcpO7Us-mp for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 07:58:12 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5C17321F8663 for <rtcweb@ietf.org>; Fri, 12 Aug 2011 07:58:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A502A39E155; Fri, 12 Aug 2011 16:57:36 +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 1ynnOfRuCUGX; Fri, 12 Aug 2011 16:57:34 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id EE11639E091; Fri, 12 Aug 2011 16:57:33 +0200 (CEST)
Message-ID: <4E453FA5.8080702@alvestrand.no>
Date: Fri, 12 Aug 2011 16:58:45 +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>
In-Reply-To: <1D062974A4845E4D8A343C65380492020625F7A6@XMB-BGL-414.cisco.com>
Content-Type: multipart/alternative; boundary="------------060808080707090503040200"
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: Fri, 12 Aug 2011 14:58:13 -0000
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 > *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