Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 09 March 2016 11:40 UTC

Return-Path: <christer.holmberg@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 4326C12DDC2 for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 03:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wybF81IGbTGK for <mmusic@ietfa.amsl.com>; Wed, 9 Mar 2016 03:40:05 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8725812DFA7 for <mmusic@ietf.org>; Wed, 9 Mar 2016 03:40:04 -0800 (PST)
X-AuditID: c1b4fb2d-f79836d000006396-b3-56e00b92cad4
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.04.25494.29B00E65; Wed, 9 Mar 2016 12:40:02 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Wed, 9 Mar 2016 12:40:01 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?utf-8?B?J0nDsWFraSBCYXogQ2FzdGlsbG8n?= <ibc@aliax.net>
Thread-Topic: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines
Thread-Index: AQHReT3F3TWg6MCKek6vzPt07YGFZJ9Pff2AgAAw3wCAADkCsIAAOumAgACMw1CAADIbAIAAG0vw
Date: Wed, 9 Mar 2016 11:40:01 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37EA257B@ESESSMB209.ericsson.se>
References: <CALiegfm7Rb4e5DFGycr=EsdigE1XFCUiqNL6+GpRSyrGe=_RWg@mail.gmail.com> <56DED735.1000101@ericsson.com> <CALiegf=G77JOcoR6DORnPsMx4OCgy=_dYQ_r8KfjMy_33vn89A@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E9EA74@ESESSMB209.ericsson.se> <CALiegf=F4z9r+oCO1DMW_nXq7TBJjf-n3N1r6yr5tLoksXtUqg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E9FDAB@ESESSMB209.ericsson.se> <CALiegf=kzThQ3n+Z-=E8G=ivyL1W=Q4gUcQenihAJ3pmv8udKQ@mail.gmail.com>
In-Reply-To: <CALiegf=kzThQ3n+Z-=E8G=ivyL1W=Q4gUcQenihAJ3pmv8udKQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbE9SncS94Mwg+VvxCym77OxmLr8MYsD k8e5hvfsHkuW/GQKYIrisklJzcksSy3St0vgylj9fBpLwT2+itVrmtkbGNfwdTFyckgImEgc 7XzPDGGLSVy4t56ti5GLQ0jgMKPE28YNTBDOYkaJdVMWsHYxcnCwCVhIdP/TBmkQEbCReD5x MSOIzSwQK/G25TFYibBAvMSTk9EQJQkS0179YoOwoyTeXb3HDFLCIqAi8aAxDCTMK+Ar8evU TKi155klvi99ygKS4BQIlFjSMZsVxGYEuu37qTVMEKvEJW49mc8EcbOAxJI956HuF5V4+fgf K4StKHF1+nImkF3MApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGMVmIZk6C6FjFpKOWUg6FjCy rGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjJuDW37r7mBc/drxEKMAB6MSD29B5P0wIdbE suLK3EOMEhzMSiK8e7gehAnxpiRWVqUW5ccXleakFh9ilOZgURLnZft0OUxIID2xJDU7NbUg tQgmy8TBKdXAmNSrskqX426aj9CG26d0C1VeiF+87KV6QFfN4vK/SWqB61LqQpIOt51c+ycx YgKzOK9wH7vwJgH974fPmb08qj9T+qb+9rsM3k/C6jl//IrtZDbJzlBv4fF6GK//lEGi70vu Nj298ge9lcL/9TgvGNdle3c3mjClqXEyyM/J4b3xd//2v8ZKLMUZiYZazEXFiQBS46DGlwIA AA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/l0yuL_ASiWQ-9OQehIUKHa1cMF4>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 09 Mar 2016 11:40:07 -0000

Hi,

>>    "For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets
>>    the offerer is planning to send for that codec."
>>
>> ...followed by:
>>
>>    "However, for sendonly and sendrecv streams, the answer might indicate
>>    different payload type numbers for the same codecs, in which case,
>>    the offerer MUST send with the payload type numbers from the answer."
>>
>> So, for sendonly, the offerer can indicate the values it is "planning" to use, but the answerer will have the final say.
>
>OK. But what would happen when such a a=sendrecv becomes a=sendonly and later a=recvonly (due "hold" feature for example)? 
>Also note that, depending who sends the re-offer, payload types may have to change within the same RTP "session".

If I could decide, endpoints would always indicate what they want to receive - even if they don't intend to receive anything (in case of inactive or sendonly).

Then, when/if you change the direction, the negotiation is already done, and you can start send/receive based on what you previously negotiated.

But, to answer your question: I don't see what the problem is. If there is an O/A where you will start receiving media, you will simply indicate what PTs you want to receive.

Regards,

Christer




--
Iñaki Baz Castillo
<ibc@aliax.net>