Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

"Cullen Jennings (fluffy)" <> Mon, 27 May 2013 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C33EF21F94F9 for <>; Mon, 27 May 2013 06:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Status: No, score=-109.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_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sfloqVcuXjjc for <>; Mon, 27 May 2013 06:27:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CCF4321F93BB for <>; Mon, 27 May 2013 06:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2687; q=dns/txt; s=iport; t=1369661233; x=1370870833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e02bNG0yLtam6ORzVsO+6S2B5+Aw1qHXpZdGkSdrpTk=; b=IOxCX0Yap1VwCyng4GcvO3KBtf5OGz+hcM8v2Nvm1dVDiVAsxYDoNWnL 6d3IAjEu2+Rhbm3ZKtw+tFhOfLLJpfKRQbTKOqX+YTrrmMddMPoJZG7/k Hed0WDnSYvwhUVxHjX2jG9pCL/GfrhZIoV55ey7WE/qJZ1a4XBRkQW8z+ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AncFADJeo1GtJXG//2dsb2JhbABagwgwwgSBBRZ0giMBAQEDATo/BQsCAQgOFBQQMiUCBA4FCId/Br13jmoCMQeCc2EDmGSQF4MPgic
X-IronPort-AV: E=Sophos;i="4.87,751,1363132800"; d="scan'208";a="212402461"
Received: from ([]) by with ESMTP; 27 May 2013 13:27:12 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4RDRCGM009514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 13:27:12 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 27 May 2013 08:27:11 -0500
From: "Cullen Jennings (fluffy)" <>
To: Colin Perkins <>
Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE?
Thread-Index: AQHOWt3kxt/fJqOvXUqSPUkSHtfgTg==
Date: Mon, 27 May 2013 13:26:29 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " WG" <>
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 May 2013 13:27:17 -0000

On May 27, 2013, at 6:29 AM, Colin Perkins <> wrote:

> 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
>   s=
>   c=IN IP4
>   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.

yes - agree of course

> 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
>   s=
>   c=IN IP4
>   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.

also agree of course 

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

Sure, suspect many people agree with you but the media pipeline is more than just the codec. So if I have 150 thumbnail videos that all using VP8, using one PT for all of them might be fine given they are all the same codec but they still might need SSRC to be able to figure out which window to render them in. I think that is all the algorithm I am proposing tries to be able to do.