Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?

Emil Ivov <emcho@jitsi.org> Tue, 25 June 2013 17:03 UTC

Return-Path: <emil@sip-communicator.org>
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 D03C421E80A3 for <mmusic@ietfa.amsl.com>; Tue, 25 Jun 2013 10:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 fAdz0WAWOWN7 for <mmusic@ietfa.amsl.com>; Tue, 25 Jun 2013 10:03:07 -0700 (PDT)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 41AA321E80AD for <mmusic@ietf.org>; Tue, 25 Jun 2013 10:03:05 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id z11so1001476wgg.3 for <mmusic@ietf.org>; Tue, 25 Jun 2013 10:03:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=tCJIS5EjFDXhQbyNZQzNZ2rkUYnXu7Zo53QxBS9C5AA=; b=W7jcr8niAaWfBnrNBEnE3JVQ5kSBBLcZqMG4YPjQJLVGAzVzUosusowbRLxUo6xSqN kdmJyRm2wQI+lkwZAdnw1GOUF/H0j5237p3CpBpRRxSuQ/sQqsVKEDh9YISQ6VQ8uMQr M3LZl2vsOxB9ZXBNKMpZ2ofbGOqsdsSspQvxbqjDk1YesTBOTcKKIYjheHRz3SavcKwT ZkleECPJaVuDozN29d+JCTY7EXvPo/KVosHd04VMDyfGtatFl3iLC2S8MmGDfJ7mSQxW RwjOlFeoMjebQmkDJX1hyZ5itjcoRmz67sTqmKj7r0SDe9qloIaKUpiihRbFYoL6YNlt Ix0w==
X-Received: by 10.194.242.136 with SMTP id wq8mr20901981wjc.60.1372179784324; Tue, 25 Jun 2013 10:03:04 -0700 (PDT)
Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPSA id d8sm5441172wiz.0.2013.06.25.10.03.02 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 10:03:03 -0700 (PDT)
Message-ID: <51C9CD45.3050404@jitsi.org>
Date: Tue, 25 Jun 2013 19:03:01 +0200
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BAA2F@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnT/Tmv1VNOIImDLag89niPwYqNdZv7pOJr0JKf9/R5tR0ck0IAoQckTVnIZzireKpxHAJU
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] DECISION: Default mechanism to map RTP data to m- line is based on PT?
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: Tue, 25 Jun 2013 17:03:12 -0000

On 25.06.13, 13:34, Christer Holmberg wrote:
> Hi,
>
> Emil suggested that the default, “MTI”, mechanism for mapping RTP data
> to m- lines should be based on PT.

Actually, what I thought was important was having it as the "default" 
mechanism. Personally I don't mind having it as MTI might but it might 
be a tad too strong: implementations that deem PT demux insufficient and 
wouldn't want to use bundle without it, don't need implement it.

We should probably also agree on how an answerer can determine whether 
or not it is expected to provide additional demuxing information (e.g. 
SSRCs) or if the offerer is using the default mechanism.

One way would be for the answerer to inspect all m= lines and try to 
detect duplicating PTs. This could be a bit clumsy though. The offerer 
could expect SSRCs but its first offer may not yet contain PT reuse.

With that in mind ... (more below)

> Applications are allowed to use
> whatever other mechanisms, but usage of such mechanisms must be
> negotiated (or, applications need to have some other means knowing that
> the other endpoint support such mechanisms).
>
> *Q3*: Do we need to specify a default, MTI, mechanism for mapping RTP
> data to m- lines?

I am in favour of having a "default" one.

Without this BUNDLE would have to be an abstract spec and I don't see 
why we would want to leave it that way.

> *Q4*: If Q3, do we mandate applications to support, and use (unless
> applications are made aware of other mechanisms supported by all
> endpoints) PT for mapping received RTP media?

In favour.

Cheers,
Emil

>
> This means that, when mapping RTP to m- lines is required (whether it is
> always mandated is discussed in another thread), within a BUNDLE group
> each PT value must be unique to an individual m- line.
>
> NOTE: If your answer to Q3 is “yes”, but your answer to Q4 is “no”,
> please indicate which mechanism you prefer J
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
https://jitsi.org