Re: [rtcweb] JSEP-19: Impact of BYE on ssrc table (Appendix B)

Cullen Jennings <fluffy@iii.ca> Fri, 17 March 2017 02:31 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0FD129BBD for <rtcweb@ietfa.amsl.com>; Thu, 16 Mar 2017 19:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level:
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 fZbvR9hCu2TJ for <rtcweb@ietfa.amsl.com>; Thu, 16 Mar 2017 19:31:05 -0700 (PDT)
Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E99129BB7 for <rtcweb@ietf.org>; Thu, 16 Mar 2017 19:31:05 -0700 (PDT)
Received: from smtp38.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp38.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9A324576E; Thu, 16 Mar 2017 22:30:54 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp38.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 32F365870; Thu, 16 Mar 2017 22:30:54 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.24.116.117] ([UNAVAILABLE]. [128.107.241.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Thu, 16 Mar 2017 22:30:54 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD0670F8-D332-4A81-94EC-6F9C51A1EF9C"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAOW+2dvyV=mpY1Qh9ZQVirgAC3YUHT6dLxs+RPicKPGg9fKenw@mail.gmail.com>
Date: Thu, 16 Mar 2017 20:30:52 -0600
Cc: RTCWeb IETF <rtcweb@ietf.org>
Message-Id: <30B46FE1-4E99-4622-8E2C-F4AA455D08D8@iii.ca>
References: <CAOW+2dvyV=mpY1Qh9ZQVirgAC3YUHT6dLxs+RPicKPGg9fKenw@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/ysVa_ln9Dhmol0fTFaF7BaBZlgE>
Subject: Re: [rtcweb] JSEP-19: Impact of BYE on ssrc table (Appendix B)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Mar 2017 02:31:07 -0000

Looking at the RTP specs ... it seems like it would not matter if an endpoint initially learned about a SSRC via RTP or SDP, either way it seems like the state for the SSRC should be mostly removed at the BYE. Thoughts on why we would handle them differently ? 

(If we do need to handle them differently, this looks like an OK approach )


> On Mar 10, 2017, at 3:31 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> In the algorithm described in Appendix B, SSRCs that are entered into the SSRC table due to signalling are not distinguished from those that are "latched" into the table dynamically.  
> 
> The distinction is important because only "latched" SSRCs should be removed due to receipt of a BYE (or a timeout). 
> 
> My suggestion of how to address this is to add a "D" flag to an SSRC table entry, indicating that the entry was added dynamically.  
> 
> For example: 
> 
>       If the packet has a MID, and the packet's extended sequence number
>       is greater than that of the last MID update, as discussed in
>       [RFC7941], Section 4.2.6 <https://tools.ietf.org/html/rfc7941#section-4.2.6>, update the incoming SSRC mapping table
>       to include an entry [with the "D" flag set] that maps the packet's
>       SSRC to the "m=" line for that MID.
> 
> Also: 
> 
>       If the packet's payload type is in the payload type table, update
>       the the incoming SSRC mapping table to include an entry 
>       [with the "D" flag set] that maps the packet's SSRC to the "m="
>       line for that payload type.  In addition, route the packet to the
>       associated "m=" line and stop.
> 
> Then when a BYE is received, check the "D" flag: 
> 
>       If the packet is of type BYE, it indicates that the RTP streams
>       referenced in the packet are ending.  Therefore, for each SSRC
>       indicated in the packet that is found in the incoming SSRC table,
>       first deliver a copy of the packet to the "m=" line associated
>       with that SSRC, but then [if the "D" flag is set] remove the
>       entry for that SSRC from the incoming SSRC table.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb