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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 05 June 2013 07:02 UTC

Return-Path: <magnus.westerlund@ericsson.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 E1A9421F9A43 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 00:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.949
X-Spam-Level:
X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 dbn+8scoT6Qy for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 00:02:50 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2853621F9A3C for <mmusic@ietf.org>; Wed, 5 Jun 2013 00:02:47 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d6d000003d54-1a-51aee29343d8
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 12.2A.15700.392EEA15; Wed, 5 Jun 2013 09:02:44 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Jun 2013 09:02:43 +0200
Message-ID: <51AEE2C6.9010809@ericsson.com>
Date: Wed, 05 Jun 2013 09:03:34 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <51A39023.1070605@alum.mit.edu> <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>
In-Reply-To: <28A125A6-FBD4-4541-892C-DE87CD79E1A9@iii.ca>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvre6UR+sCDT4sYrf4sP4Ho8XU5Y9Z LFZsOMDqwOzx9/0HJo8lS34yeVw+/5ExgDmKyyYlNSezLLVI3y6BK2P+s4tMBS0KFWv+P2Rs YNwj2cXIySEhYCLxubOPGcIWk7hwbz1bFyMXh5DAKUaJWzv3QznLGCXefbgHVsUroC1xfuUF NhCbRUBF4nbPCiYQm03AQuLmj0awuKhAsMSR7ZtZIOoFJU7OfAJmiwgoS5zbcRdsDrOApcSK rkawuLCAtcSzhidQy/oYJfpXXQEbxClgJfHx5iYmiPMkJba8aGeHaNaTmHK1hRHClpdo3job bKgQ0HENTR2sExiFZiHZPQtJyywkLQsYmVcxsucmZuaklxtuYgSG8MEtv3V3MJ46J3KIUZqD RUmcV493caCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRmaBj3v/nv2pueLK04dFT4OPFUaH p/HnOPfxveQXzj13+/znHRaPPkfk33YX++CZYOsc/UDiRvvl3Iemody/nWqUVXNv79u2Otvt eatkRd2CRWInExZM6Q46zrrrx/13MuFO9UcfrPhZ1S+w8O78OWIfxdUXL6j9Xrp5+qdrUv3L nyh4K3Ten6jEUpyRaKjFXFScCAAg1KW1LwIAAA==
Cc: mmusic@ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Wed, 05 Jun 2013 07:02:57 -0000

Hi,

Jumping into this late. But, I do Share almost all Colin Perkins has
written on this. And I think this discussion has gotten down to the gist
of things.

First of all, with Bundle you will have multiple m= blocks describing
the same RTP session, that combination must offer a consistent RTP
session definition. Thus, each used PT number must map to a unique
payload format and payload format configuration. However, I believe it
is important that we do allow the same PT == codec + payload format
configuration to be reused over multiple m= blocks, otherwise we will
shortly run into a scarcity issue with PT numbers.



On 2013-06-04 00:51, Cullen Jennings wrote:
> 
> 
> Imagine Alice sends  an offer containing 
> 
> On May 27, 2013, at 10:56 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
>> m=audio 49172 RTP/AVP 96
>>  a=ssrc:2222 cname:alice@example.com
>>  a=rtpmap:96 G7291/16000
> 
> Let say that an offer sent like the above. That means nothing about the SSRC for the packets that Alice will receive. And it is likely to receive RTP packets before it receives an answer in some important scenarios. 
> 
> So a RTP packet SSRC 3333 arrives. There's no information from the SSRC about what m-line it matches too (but RTCP for it can be sent). 

Not only can RTCP be sent, the packets are identified to be a new stream
(due to new SSRC) and you know how to decode them. It is the binding
between the m= line and any application logic on how you intended to use
a stream that is missing.

This is a general problem and should be solved in a general way. Yes, we
could rely on requiring explicit SSRC signaling to bind it to a m=
block, or we can look at solutions that include the necessary
information somewhere where we are not having an issue with what arrives
first, i.e. we need something that can be included in the media plane,
i.e. RTP/RTCP and which can be bound to the signaling information
providing the application with the intended usage of a particular set of
streams.

> 
> Now an answer from Bob arrives with 
> 
> m=audio 55555 RTP/AVP 96
>  a=ssrc:4444 cname:bob@example.com
>  a=rtpmap:96 G7291/16000
> 

> Now a packet with SSRC 4444 arrives. That might be from Bob, but
here's the rub. It might be from Charlie. If there was an SSRC
collisions between Bob and Charlie, it will be awhile before some SDP
shows up that says that there was a collisions and now Bob is using SSRC
5555.

Yes, there can be a SSRC collision. However, the RTP/RTCP layer will be
able to detect this, at the latest when two differnet CNAMEs claim to
use SSRC 4444.

> 
> This is all a disaster and the best solutions to it IMHO would be to
define a new RTP Header extension that carries and identifier and that
Alice can tell Bob in the SDP offer what value to put in the identifier
for the RTP from Bob to Alice.

I don't know if it is a disaster, as SSRC collision may occur but can be
sorted out and offers a glitch. I think a more likely glitch is due to
the general mismatch between relying on timely signaling of O/A and
dynamic behaviors among the media stream.

I think I am supporting the general idea of providing the "this is what
this stream is used for" in RTP/RTCP. My current thinking makes me
prefer a RTCP Source Description Item (SDES Item) which can also be
stuck in an RTP header extension to speed up acquiring the binding when
introducing a new stream and you can't really know that RTCP has made it
yet. That way each m= block, can have a short "usage tag" that is sent
as the SDES item for all RTP streams.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------