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

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Fri, 12 August 2011 14:11 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 0129D21F8A23 for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 07:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.098
X-Spam-Level:
X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 775Qd-1mWXt7 for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 07:11:34 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF721F89BE for <rtcweb@ietf.org>; Fri, 12 Aug 2011 07:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=44452; q=dns/txt; s=iport; t=1313158330; x=1314367930; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=KbT3AAjEHrOVwAq4h+HcrwxkYV+K/KrI8a/J5fobyfk=; b=CNeCqX2OAUR2fwLszJ0sRM0jrpvzVvqmFZoJYp6QUiw6aAkwEAfydX8L pSapZjo2USG40xgoC7wmlx0GiBST+Tql9p2KncCRVyf4WdtXLrPusLjwh tC6I4vip5PoD82vN19q/F2dEUtVj2mTbIAGQqO31tJaQJ/AiFvMZEl/C4 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtcAAAY0RU5Io8UQ/2dsb2JhbABBgk2VW49Pd4FAAQEBAQMBAQEPAQkRAzcHCwwEAgEIEQMBAQELBhABBgEGASUBHwkIAQEECwcBCAESB4dRmxsBnnSFaF8Eh12QSIRhhwM
X-IronPort-AV: E=Sophos; i="4.67,362,1309737600"; d="scan'208,217"; a="50227624"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 12 Aug 2011 14:12:08 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7CEC71f022084; Fri, 12 Aug 2011 14:12:07 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); Fri, 12 Aug 2011 19:42:07 +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_01CC58F9.D1350FE2"
Date: Fri, 12 Aug 2011 19:42:06 +0530
Message-ID: <1D062974A4845E4D8A343C65380492020625F7A6@XMB-BGL-414.cisco.com>
In-Reply-To: <4E45282D.3000306@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: AcxY8oqfjrP+hMf3R4GJe2f9EtKuegABNiLQ
References: <4E43BDB3.8000504@alvestrand.no> <1D062974A4845E4D8A343C65380492020625F795@XMB-BGL-414.cisco.com> <4E45282D.3000306@alvestrand.no>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>
X-OriginalArrivalTime: 12 Aug 2011 14:12:07.0675 (UTC) FILETIME=[D1CB14B0:01CC58F9]
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:11:36 -0000

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