Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description

Bernard Aboba <bernard.aboba@gmail.com> Fri, 03 February 2017 03:43 UTC

Return-Path: <bernard.aboba@gmail.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 83B9E127071; Thu, 2 Feb 2017 19:43:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0de8FMsJiEBJ; Thu, 2 Feb 2017 19:43:12 -0800 (PST)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 4D9F7126BF7; Thu, 2 Feb 2017 19:43:12 -0800 (PST)
Received: by mail-pf0-x242.google.com with SMTP id y143so596420pfb.1; Thu, 02 Feb 2017 19:43:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UCIt8LBLa2yaD9zrT15p3PRa9qLLuSz9jb8i1T7jdSg=; b=FNYIWBc/BQgoFMsuZd6XVQxBqafWz0I74bGpbeQX9CqfwZvC+51ClKsWAiOWoVolUn IKWAQAH97xlddFHCM0Jwotj2xkG4GqYtTtckEHDnHteK4L98z0p39qYsyAIau6XRmeCQ H/wy3oT3GWuLPJCUzrmSxiM5rkUaQ9Q1FHXua3QQp3YdOSX6br8chnVEikFonofYV3Z6 UZuhW05pANERpC5g6D55qzwKZvtWA+9iS6WGzPaVvPV05tuXoWj0PygcSu9vPb1gyXFQ gyDAe9Zuomnm5eCq52luPDMh1att+YeDIwSiUWpnjDsSh6lRWl3/6LzDDWCWKw3kWON/ FY+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UCIt8LBLa2yaD9zrT15p3PRa9qLLuSz9jb8i1T7jdSg=; b=HZrUwI4wuARCwjeSd+jCtxV8Z1uJsLHooaVyLVTNFgaFAAngK2FMtcnmZRryub9bJg MDcJdcxAObfhUpfjzx6sWTKPw/YhfK5gQbyBnvqMjgGIaOhRZtWqlv/RDQuAtjedr76Q 1BNe0r6qrTqwyaP13ZovQ6L10u89t7JTifxgdAreHuzJlJuV39ZxnTXKKZm4XmDDNOPW r6JGhLa+DqfscsLEehyM8PMtJvpMQMzDzC9eap9OJZ/SqOH8NRJP4ndPCKPsUHLcGqfW K2/tQ4eb1A9iRylt3qPGMWbdS/gJjcsNgH0IOi65ispSyvb/JP1wbW/9GaNhbEq46zFS x1nA==
X-Gm-Message-State: AIkVDXJpUD51rM7MuzCJnl71ZQP3MltRKXEr5H6Bk999Y4EzoW3xvzTnPFRF5uz2As0RDQ==
X-Received: by 10.98.212.23 with SMTP id a23mr15423316pfh.18.1486093391775; Thu, 02 Feb 2017 19:43:11 -0800 (PST)
Received: from [10.69.52.226] (mobile-166-176-184-127.mycingular.net. [166.176.184.127]) by smtp.gmail.com with ESMTPSA id r8sm62142358pfi.82.2017.02.02.19.43.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 19:43:10 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca>
Date: Thu, 02 Feb 2017 19:43:09 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <61E68192-A460-4F6D-BC31-28C459D63756@gmail.com>
References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <D2A63CD5-61AB-47DD-B946-6A17A94F76E7@vidyo.com> <7ED35CA1-D90C-444A-93EF-445C894B6859@iii.ca>
To: Cullen Jennings <fluffy@iii.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/JgXO9fB0TK8y_R99mhOtDWjCfu8>
Cc: Jonathan Lennox <jonathan@vidyo.com>, "draft-ietf-rtcweb-jsep@tools.ietf.org" <draft-ietf-rtcweb-jsep@tools.ietf.org>, RTCWeb IETF <rtcweb@ietf.org>, mmusic <mmusic@ietf.org>, "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" <draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description
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: Fri, 03 Feb 2017 03:43:13 -0000

Assuming the collision is detected and B sends a BYE then once the SSRC latch is removed then A's packets will match on PT, a new SSRC latch is put in place and everything works.

> On Feb 2, 2017, at 2:19 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> 
>> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>> 
>> In general, this looks good.
>> 
>> I have one question, however.  What should happen if an RTP packet (without a MID) is received for a stream that has an existing mapping to an m= line, but whose PT is not valid for that m= line?
>> 
>> Should it
>> 1. Cause the stream’s mapping to be moved to another m= line, if the received PT is in the payload type table for some other m= line?
>> or 
>> 2. Be an error?
> 
> 
> Imagine a case where we have two sends call A and B and they each use one PT that is unique and go to different m lines on receiver C via a SFU.  Initially C get a packet from B with a given SSRC and the PT and creates a mapping for it. But imagine that A and B had an SSRC collision which they sort that out and A ends up having the SSRC that B initially used. If you don't have the PT override the SSRC, the packets are going to go to the wrong m-line because the PT points at the m-line A is using but the old SSRC incorrectly points at the m-line B is using. 
> 
> To put this a different way, if the packet has a mid, I think it is very clear the mid has to override the PT. Same for the PT. The mid is effectively just an extended PT. 
> 
> I'm not thinking to much about the case where SSRC is signalled in SDP but ignoring that case for a second, I think the really easy thing to specify, implement, and understand works is simply a priority order where roughly 
> 
> 1) if you have mid, use that and latch the SSRC
> 2) if you have a unique pt, use that and latch the SSRC 
> 3) if you have a latched SSRC use that 
> 
> If you had signaled SSRC, guess I would insert that as step 1.5 of use that 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb