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