Re: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 17 August 2011 09:27 UTC

Return-Path: <mperumal@cisco.com>
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 5466321F8548 for <rtcweb@ietfa.amsl.com>; Wed, 17 Aug 2011 02:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.084
X-Spam-Level:
X-Spam-Status: No, score=-10.084 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
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 bhTH9ZArpx2F for <rtcweb@ietfa.amsl.com>; Wed, 17 Aug 2011 02:27:04 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 02F4721F8520 for <rtcweb@ietf.org>; Wed, 17 Aug 2011 02:27:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=53775; q=dns/txt; s=iport; t=1313573274; x=1314782874; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=yn4pGL2wPtd0zPbUxvLpF4A8TM8hqttFQyge/BUn0aQ=; b=FV0dqbgrRoxVcdbqyLGmivQXf6GVD00ie3e5pxDDPAGiCbeAxMQxVaYI 3GUVWAzKqz9NM2kHqUvA+EiDiyqv8aqjfYSANE7fXRJ0pQmu8SmUKJoud XOG9noAVnDinycoxebsKVYvSyzFJJmE5otgMRCrV2DEFUJ/RbQpis5y/7 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As8AAHmJS05Io8US/2dsb2JhbABCgk2WPY9Sd4FAAQEBAQMBAQEPAQkRAzcHCwwEAgEIEQMBAQELBhABBgEGASUBHwkIAQEECwcBCAESB4dSmlYBnyqFaV8Eh16QSoRihwY
X-IronPort-AV: E=Sophos; i="4.68,238,1312156800"; d="scan'208,217"; a="111194828"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 17 Aug 2011 09:27:27 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7H9RR89030669; Wed, 17 Aug 2011 09:27:27 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 14:57:26 +0530
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC5CBF.E09890CA"
Date: Wed, 17 Aug 2011 14:57:24 +0530
Message-ID: <1D062974A4845E4D8A343C65380492020625FDC5@XMB-BGL-414.cisco.com>
In-Reply-To: <4E453FA5.8080702@alvestrand.no>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Fwd: I-D Action: draft-alvestrand-one-rtp-00.txt
Thread-Index: AcxZAGCxw6ZyDysMQFSO2JD7Rvno3gDvFAAA
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>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>
X-OriginalArrivalTime: 17 Aug 2011 09:27:26.0912 (UTC) FILETIME=[E0EE3C00:01CC5CBF]
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:27:06 -0000

|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).
 
|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.
 
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
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] On Behalf
Of Harald Alvestrand
Sent: Thursday, August 11, 2011 5:02 PM
To: 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
Reply-To: 
internet-drafts@ietf.org
To: 
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
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt