[MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-01

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Sun, 04 November 2012 06:23 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2897021F84AF for <mmusic@ietfa.amsl.com>; Sat, 3 Nov 2012 23:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.099
X-Spam-Level:
X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZYa8yUoadV5 for <mmusic@ietfa.amsl.com>; Sat, 3 Nov 2012 23:23:11 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4A22921F8450 for <mmusic@ietf.org>; Sat, 3 Nov 2012 23:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3013; q=dns/txt; s=iport; t=1352010191; x=1353219791; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=31BshKNTDayAIb+A/PdqRpUuc/RtxO7DnD8hggYjbKc=; b=Znej31yEevWcr58YKpNS48s6Vncsf6EXJDlu6WcnBo/I57CtcZwDZzlH WDiS2gku0Yfu8Pn7pLO+8VwJ42ICf/cGdqAIc2wS9CHmysFl4pUaF3q2u L5dtFJr6rXzPhzbs0MJTtU/saw1Gne3Nrov2jxw+uAOidunChgk26OLxm Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPYIllCtJV2Y/2dsb2JhbABDwzmBCIIgAQQSASdRASoUQiYBBBsah2iYbIErnxCRXGEDpFSBa4Jvghk
X-IronPort-AV: E=Sophos;i="4.80,707,1344211200"; d="scan'208";a="138565491"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 04 Nov 2012 06:23:10 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA46NAcd026003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Sun, 4 Nov 2012 06:23:10 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 01:23:10 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: comments on draft-ietf-mmusic-sdp-bundle-negotiation-01
Thread-Index: Ac26VNtR0qWHHOkKTYGtONEogV5B3Q==
Date: Sun, 04 Nov 2012 06:23:09 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C088281048DF@xmb-aln-x08.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.92.222]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004
x-tm-as-result: No--43.082000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2012 06:23:12 -0000

I have a few of comments on this draft, mostly in regard to the description of the offer/answer procedures.

1) Section 6.2 end as follows:

   If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has
   reasons to believe that the rejection is due to the usage of a single
   port number value for multiple "m=" lines, the SDP Offerer SHOULD
   send a new SDP Offer, without a "BUNDLE" group, where a separate port
   number value is provide for each "m=" line of the SDP offer.

I think this was meant to be as follows:

   If an SDP Offer, offering a "BUNDLE" group, is rejected, and the SDP Offerer has
   reasons to believe that the rejection is due to the usage of a single
   port number value for multiple "m=" lines, the SDP Offerer SHOULD
   send a new SDP Offer, without a "BUNDLE" group, where a separate port
   number value is provide for each "m=" line of the SDP offer.

Additionally, on what basis would the offerer have "reasons to believe the rejection is due to the usage of a single port number value"? Perhaps if it is the initial INVITE, this assumption is made, whereas if this is a re-INVITE following a previously successful negotiation, it is assumed to be some other case? This seems strange to me. I think it is better to remove the "reasons to believe" qualifier.

2) Section 6.4.2, reads:

   The total proposed bandwidth is the sum of the proposed bandwidth for
   each "m=" line associated with a negotiated BUNDLE group.

I'm afraid this is an overly simplistic approach. For example, a typical video call with content sharing includes one audio m-line and 2 video m-lines. The bandwidth is declared at the session level as well as at the media level, but the sum of the media levels is typically greater than that of the session level. When content sharing occurs, it steals some bandwidth from the main video. In the case of BUNDLED m-lines, the proposed bandwidth should therefore be the lesser of the sum of the BUNDLE m-lines and the session bandwidth.

3) Section 7.2 reads,

   o  - A given SSRC SHOULD NOT transmit RTP packets using payload types
      that originates from different "m=" lines.

   NOTE: The last bullet above is to avoid sending multiple media types
   from the same SSRC.  If transmission of multiple media types are done
   with time overlap RTP and RTCP fails to function.  Even if done in
   proper sequence this causes RTP Timestamp rate switching issues [ref
   to draft-ietf-avtext-multiple-clock-rates].

Why not replace the text in the bullet point with the text from the note, i.e.

   o  - A given SSRC SHOULD NOT be used for sending multiple media types .
 
   NOTE: If transmission of multiple media types is done
   with time overlap, RTP and RTCP fail to function.  Even if done in
   proper sequence this causes RTP Timestamp rate switching issues [ref
   to draft-ietf-avtext-multiple-clock-rates].

Cheers,
Charles