[MMUSIC] Scope of RTP payload types in BUNDLE?

Colin Perkins <csp@csperkins.org> Mon, 27 May 2013 12:29 UTC

Return-Path: <csp@csperkins.org>
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 6041021F93EB for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 05:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.999
X-Spam-Level:
X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, 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 4xs6w0ipk8Bj for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 05:29:44 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2B21F9397 for <mmusic@ietf.org>; Mon, 27 May 2013 05:29:44 -0700 (PDT)
Received: from [81.187.2.149] (port=37947 helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1UgwYZ-00072H-3M for mmusic@ietf.org; Mon, 27 May 2013 13:29:43 +0100
From: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 May 2013 13:29:41 +0100
Message-Id: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org>
To: "mmusic@ietf.org WG" <mmusic@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Subject: [MMUSIC] Scope of RTP payload types in BUNDLE?
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: Mon, 27 May 2013 12:29:50 -0000

There were a number of comments in the call last week, and on the list, about unique payload types in BUNDLE. I'd like to explore this further.

Case A: Within a single RTP session, I think we'd all agree that an offer that uses the same RTP payload type for two payload formats on a single m= line is problematic: 

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 96
   a=rtpmap:96 AMR-WB/16000
   a=rtpmap:96 G7291/16000

If this were done the receiver would have no way of distinguishing what payload format is meant by payload type 96. Accordingly, unique payload formats need to be used for each payload format.

Case B: If one were to use two separate m= lines on different ports, in the non-BUNDLE case, then the same RTP payload type can be reused without difficulty:

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
   s=
   c=IN IP4 host.anywhere.com
   t=0 0
   m=audio 49170 RTP/AVP 96
   a=rtpmap:96 AMR-WB/16000
   m=audio 49172 RTP/AVP 96
   a=rtpmap:96 G7291/16000

The implication is that there are two separate RTP sessions, which the receiver can distinguish based on the UDP port on which the packets are received. The mapping from RTP payload types to payload formats is done on a per-RTP session basis.

Case C: This is when we BUNDLE several m= lines on a single UDP port. On the call last week, there seemed to be agreement that the m= lines in such a BUNDLE group comprise a single RTP session (it also matches the definition of an RTP session from RFC 3550: the packets go to a single destination and the m= lines share a single SSRC space). To me this would suggest that the RTP payload type values MUST be unique across the m= lines (or, if the same RTP payload type is used in different m= lines, it MUST map to an identical payload format). The reason is that everything runs over one UDP port, and if a single RTP payload type is mapped to different payload formats, there's no way to distinguish which payload format is meant. This is essentially the same as case A above.

Given this, it's not clear to me that non-unique payload types make sense within a BUNDLE group. They work on different m= lines in the legacy case because those lines form different RTP sessions, and the RTP sessions can be used to scope the payload type to payload format mappings. I don't see that they work in BUNDLE, because there's a single RTP session, and so a single mapping from payload type to payload format.

-- 
Colin Perkins
http://csperkins.org/