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
>   
>