Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B

Peter Thatcher <> Fri, 24 March 2017 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B452F12999F for <>; Fri, 24 Mar 2017 14:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SQ92FNCmrWbD for <>; Fri, 24 Mar 2017 14:46:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BBA71299B2 for <>; Fri, 24 Mar 2017 14:46:17 -0700 (PDT)
Received: by with SMTP id r45so2218483qte.3 for <>; Fri, 24 Mar 2017 14:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dXuI/guVECndCPp7ydTtpGJofjj6CaN2TU1VLzZ0u5k=; b=deEIih1KUqehSP9gu60Kmu+BawBYF6LFovVF84L0CpujAJBu/GD8KbD1vKEn3sssCz 1OCbDYv0HoIfyz1Yq8dBGjZtmZMvAQcnngPLH/ebXOtDgnAipaP8n2/hdVtpudZ1p+Yp wQJOjLnXmqWDW3lhPpay5a2wTZU6YG5GQvI8wngtMwAoishdeIlT9hB7axMMK52xn2DE sFGeGYwT+3Nh70g9HfyZo59fVCpwxeVfh3iYWFbJPr9AvP+ULA/qtFRxBz+kX8iCNWtl ARREl6bwDcwjEpvMLfVS88CdmTXvVL+/JO7fa9h5pP/IC46vQP3eLZogwDTjjOmpn4Kl ZrlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dXuI/guVECndCPp7ydTtpGJofjj6CaN2TU1VLzZ0u5k=; b=SoR+mft+PYtYgKmYMlSMepaDZIRdoAQcfAm2WKQ1OOJA2HhA0XoMvDtPs4Y9ILwbPz tRfI+gsxkmwaTDj2n0jES+TnAkENFddTjqf/E14svZSX2iplS5G452a3HSEq+8wmzPbK yV8ig9jiwb/iaMzFz9Lw+WKt25RT65tWm53INEgWHYTm86eB93HZeABzVFPWqR+H1Iaz KD5MAOyRes+16ksx+qilsXPgjq1K25/oMBR5qEkqBJsXMi/qHO0CgWZ+Nm4Pu8K8ulWV ai8d/ANqouwwpqScsTWooFpD3clS0ViE2W8qjmqVRPoROQYdgkU4VRrNkgJgaeyIia17 wEaQ==
X-Gm-Message-State: AFeK/H28XQQOHjBUHbGcxUML3Mk7iF2QC9YfiY7PFb+ICbnmRKPHO65uqhRyCcz8eC2hk11CEkygWddgvtM/DKmy
X-Received: by with SMTP id i90mr9650051qtb.262.1490391976477; Fri, 24 Mar 2017 14:46:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Peter Thatcher <>
Date: Fri, 24 Mar 2017 21:46:06 +0000
Message-ID: <>
To: Magnus Westerlund <>, Ted Hardie <>, "" <>, Sean Turner <>, Cullen Jennings <>, "mmusic (E-mail)" <>
Content-Type: multipart/alternative; boundary=001a1140584e55e37b054b80ec13
Archived-At: <>
Subject: Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Mar 2017 21:46:20 -0000

To address your first two issues, I have made two PRs for JSEP:

Please take a look and see what you think.

On the issue of being a packet-based algorithm, I think the existing text
addresses that fairly well:

      Applications can implement RTP stacks in many different ways.
      The algorithm below details one way that demultiplexing can be
      accomplished, but is not meant to be prescriptive about exactly
      how an RTP stack needs to be implemented. Applications MAY use
      any algorithm that achieves equivalent results to those described
      in the algorithm below.

On the issue of future extensions of RTCP, I feell confident that the
authors of future extensions can write their text in a way that works well
with this algorithm if it's necessary.

On Fri, Mar 24, 2017 at 3:49 AM Magnus Westerlund <> wrote:

> Hi,
> This email is specifically concerning Appendix B and I CC MMUSIC as the
> text is being transfered to BUNDLE.
> First Issues that I think needs to be addressed.
> 1. PT based mapping:
>        If the packet's SSRC is in the incoming SSRC mapping table, check
>        that the packet's PT matches a PT included on the associated "m="
>        line.  If so, route the packet to that associated "m=" line and
>        stop; otherwise drop the packet and stop.
> I think the text should be clearer on the limitation of PT based mapping
> versus MID based, that following this algorithm, an SSRC is not possible
> to move from one media description (m=) to another after the initial
> mapping. This probably belong to the earlier discussion of PT based
> mapping, but the above quote is the reason for that limitation.
> 2. RTCP BYE handling:
>     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 remove the entry for that SSRC from the
>        incoming SSRC table.
> This has been discussed on the list, but I want to reinforce that the
> more reasonable action is to mark the entry for removal, and then after
> a short timeout (some seconds), allowing any re-ordered or delayed
> packet to arrive and be processed, remove the entry.
> 3. I think it is time that this text is moved into bundle and removed
> from JSEP document.
> Then I have a reservation against this text. I call it a reservation as
> it is something I do not require a text change for, but which I wished
> was addressed. But at the same time I have been unable to properly
> engage and work on an updated text that helps address the issue.
> My reservation is that the text is written from a very RTP/RTCP packet
> centric way, and from the perspective of a highly integrated
> implementation. I would much have preferred that it was written in an
> RTP stream centric way and from the perspective of a modularized RTP
> stack implementation with some abstract API between the higher layers
> consuming the RTP streams and handling any RTCP feedback messages. That
> way the focus could have been on when to create and update the RTP
> stream to higher layer "m=" association. RTCP handling is unfortunately
> very dependent on what API model one has, and is therefore tricky to
> describe as it is dependent on the API, and what it provides versus hides.
> The risk with the text as it is currently written is that the
> implementers of WebRTC endpoints that uses generic RTP/RTCP
> implementation modules may have significant issues with mapping the
> current text to the API they will see.
> The second aspect of the text which may be problematic is how future
> proofing of it in regards to RTCP. If new RTCP feedback messages,
> Extended Reports (XR) or other new RTCP functionality is introduced it
> may be challenging to map that to the new messages. However, I thank the
> authors for especially improving this aspect in regards to RTCP feedback
> messages.
> Cheers
> Magnus Westerlund
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> <+46%2010%20714%2082%2087>
> Färögatan 6                 | Mobile +46 73 0949079
> <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto:
> ----------------------------------------------------------------------
> _______________________________________________
> mmusic mailing list