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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 May 2013 18:49 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 0A47B21F8DB7 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 11:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.463
X-Spam-Level:
X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
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 uM+8CXekLYVV for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 11:49:43 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A373F21F8AD1 for <mmusic@ietf.org>; Mon, 27 May 2013 11:49:41 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id h6V71l0050bG4ec516phKf; Mon, 27 May 2013 18:49:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id h6pg1l00w3ZTu2S3P6pgxB; Mon, 27 May 2013 18:49:40 +0000
Message-ID: <51A3AAC3.9030905@alum.mit.edu>
Date: Mon, 27 May 2013 14:49:39 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <B7E3612F-241F-4119-A973-12D3F7DB36BC@csperkins.org>
In-Reply-To: <B7E3612F-241F-4119-A973-12D3F7DB36BC@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369680581; bh=WtnAJJcpdOn2UCE+n7jGe3GLEcxD/p3A1Gxnn804q80=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OCFRTxDc8KpUKIrVyHKl90v0lApS5VwsLHYSBantuY1EcO7J57Y1H93ax3ym07gsk 23fVaynJfHPNQpHRHvgBlvzBr6kEuC+BPyNEiaoGHQNuAaH+G/iub9LR8Lzxe74Nkq 2pwwhm6YbM2Z/H8r+FYfzF1fY1PvBSK4WBBysyjvxSI9DjM629QMUjllSZny+INGHw cA8wHeutVB1rXLrkZPtEt356t0yxgCd9X9WY3ylKH65s4ulYw8U5zi71R4DNpXmtI5 VJE6nx3UX5rcwE0T4DpixjHsaU5CtNszoPP+tLmCyRcCJuDR8Dhko24Xe0kv8YoWWl sfgOj3f4u3ktg==
Cc: mmusic@ietf.org
Subject: Re: [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 18:49:48 -0000

On 5/27/13 2:29 PM, Colin Perkins wrote:
> Paul,
>
> What would that other characteristic be? The only thing you have is the SSRC, and SDP doesn't scope "a=rtpmap:" lines to be per "a=ssrc:" line, and RTP certainly doesn't treat payload types as per SSRC.

This is all part of defining the precise semantics of bundling!

In the example I gave below, what I am suggesting is that:

- SSRC 1111 is associated with m-line X, and SSRC 22222 is associated
   with m-line Y.

- When a packet is received, it must first be associated with
   an m-line. If it has SSRC=1111 then it can be associated with
   m-line X. Then, m-line X gives the mapping of PT 96 to audio
   and AMR. If it has SSRC=2222 then it can be associated with
   m-line Y. Then, m-line Y gives the mapping of PT 96 to audio
   and G.7291. (If a packet with some other SSRC is received
   then the mapping to an m-line is unknown, unless we introduce
   some other rule.)

- in some other example, if some PT is unique to a single m-line,
   then a packet with that PT can be associated to that m-line.

Have I made myself clear yet?

	Thanks,
	Paul

> Colin
>
>
>
> On 27 May 2013, at 17:56, Paul Kyzivat wrote:
>> Colin,
>>
>> As I suggested on another thread, ISTM that it should be possible to reuse the same PT to map to different payload formats in different m-lines of a bundle *if* there is some other characteristic declared in SDP and present in packets that can be used to associate the packet to one m-line. In that case, after picking the m-line, the mapping from PT to payload format for *that* m-line can be used. E.g.,
>>
>>    v=0
>>    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
>>    s=
>>    c=IN IP4 host.anywhere.com
>>    t=0 0
>>    a=group:bundle X Y
>>    m=audio 49170 RTP/AVP 96
>>    a=mid:X
>>    a=ssrc:1111 cname:x@example.com
>>    a=rtpmap:96 AMR-WB/16000
>>    m=audio 49172 RTP/AVP 96
>>    a=mid:Y
>>    a=ssrc:2222 cname:y@example.com
>>    a=rtpmap:96 G7291/16000
>>
>> 	Thanks,
>> 	Paul
>>
>>
>> On 5/27/13 8:29 AM, Colin Perkins wrote:
>>> 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.
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>