IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 08 March 2016 23:34 UTC

Return-Path: <ibc@aliax.net>
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 230CF12DC30 for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 15:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
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 8VH6HsTbOD7O for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 15:34:29 -0800 (PST)
Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5087512DC2D for <mmusic@ietf.org>; Tue, 8 Mar 2016 15:34:29 -0800 (PST)
Received: by mail-yk0-x22c.google.com with SMTP id y66so13435470ykd.2 for <mmusic@ietf.org>; Tue, 08 Mar 2016 15:34:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=abhqoqPOihFW+Ml59i/gVbelb7Kq/iI6Dke+9lJLenE=; b=VvBjhc1VlVZpQ3TDIWby6iywa2ZvcPFgUwSAQLWD53iBYCqClPI2fypN34uYID0EKM RKwqYS5y37cydyAHR3iTku4xEh4EngHXX/WIJg7AXrI9c27Hq4jr6fzzdIzH4z21V4j6 EfJurcamcBuW+v9eYprCVO/K6DRxTdLq9Qk8uNvRTM9uytPzxDRjih2UMmaCrklYzulM pOoAxa06zJxWvKFurmOxUo/6WS+LKTWrPfowCFBsu0E8thLZ7ZQ9LEgqY0w9xMInc0Bs 6LJwn+jg2E0dOWb7bVpjnSnRpy4iGLr64VPiGjFNHQp5YUnX/+/Tuv6Y9f0gQI06VZWd 3cYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=abhqoqPOihFW+Ml59i/gVbelb7Kq/iI6Dke+9lJLenE=; b=jYhFnWgSh1cB3tijQCQ85NdDzL/6PVVWTRdIxkLfz5mceZkcFaAbIrcRRcnq1ffZbA bo3CyIM0S3NSfLAZCtV5+kYdnAxNAkcm02reDi+j4lzydcTiH22HYiG1Rr/nLEUrdfeL 3DTj7dzV9uuha0tUIlBnQ5Vk22HnRXBrpAjkt5g7ZEvGhsOsdGWzXO7esTjrSRU1hulG iIT9msv2A+fT6/+8qcXxZlDe+m3mOvmBM7zJLRNXcGespgWSwYtudLEd+lBcBuWHWf6s aCKxY+Vc6awrRMrj/8Fu4OEgy8yKtegNLWYXXq7vXxcRv9a430CXqkeKN0kB5p7pX9ZP t5nQ==
X-Gm-Message-State: AD7BkJLgzaAujZHnM3c0493Bjym9k9XD+S2QNQWE1XzXOqNq4gW6QHH1QEyQEvbByP10mzLf8EamKATgviy7sA==
X-Received: by 10.37.85.67 with SMTP id j64mr17465355ybb.172.1457480068535; Tue, 08 Mar 2016 15:34:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.201.132 with HTTP; Tue, 8 Mar 2016 15:34:09 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E9EA74@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>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 09 Mar 2016 00:34:09 +0100
Message-ID: <CALiegf=F4z9r+oCO1DMW_nXq7TBJjf-n3N1r6yr5tLoksXtUqg@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/GT5oAtfB29wU4CC-gA1W0fXyhuI>
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: Tue, 08 Mar 2016 23:34:31 -0000

2016-03-08 20:05 GMT+01:00 Christer Holmberg <christer.holmberg@ericsson.com>:
> When we discussed payload type mappings and RTP sessions, it was said that, in a sendonly m- line, the payload type values are simply "place holders", the remote endpoint will tell you what values it want to receive.
>
> So, in your case, you can't say "I am going to send you with PT 100". The answerer is going to say what it wants to receive, so in your case it may e.g. chose 98 for alice-audio and 99 for bob-audio.

So I tell you that I will send N codecs with SSRC 1234 and you tell me
which payload I should use. This makes no sense IMHO. SDP was designed
for 1-to-1 symmetric (audio) streams. When it comes to multi-stream (I
send my audio and video and receive multiple audio and video streams
from others) SDP becomes a nightmare.


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

v2.46.0 | Report a Bug | By Email | System Status