Subject: [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt

From: Ted Hardie <[email-masked]>
Date: Fri, 10 Mar 2017 11:21:53 -0800

Dear working group,

This institutes a working group last call on draft-ietf-rtcweb-jsep-19.txt,
lasting until March 24th, 2017.

Please raise issues you find with the draft on this list; if you prefer to
use github, please let me or one of the other chairs know that you'd like
us to move the issue to the list.

A major agenda item for us in Chicago will be working through any issues
that the working group finds, and the chairs intend to forward the result
to the IESG as soon as possible after the meeting.

Thanks for attention to this,

Ted, Sean, Cullen

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Mar 10, 2017 at 11:12 AM
Subject: I-D Action: draft-ietf-rtcweb-jsep-19.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Real-Time Communication in WEB-browsers of
the IETF.

        Title           : Javascript Session Establishment Protocol
        Authors         : Justin Uberti
                          Cullen Jennings
                          Eric Rescorla
        Filename        : draft-ietf-rtcweb-jsep-19.txt
        Pages           : 116
        Date            : 2017-03-10

Abstract:
   This document describes the mechanisms for allowing a Javascript
   application to control the signaling plane of a multimedia session
   via the interface specified in the W3C RTCPeerConnection API, and
   discusses how this relates to existing signaling protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-19

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft
<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>
directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 11 Mar 2017 14:57:54 +0000

Hi,

Version -19 still contains Appendix B, which is still work in progress - and I am not only referring to the ondoing BYE/ssrc discussion, but the whole RTP-to-m-line mapping issue.

So, if you want to issue WGLC, shouldn’t we remove Appendix B first (as it is anyway intended to be moved to BUNDLE)?

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: 10 March 2017 21:22
To: [email-masked]; Sean Turner <[email-masked]>; Cullen Jennings <[email-masked]>
Subject: [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt

Dear working group,
This institutes a working group last call on draft-ietf-rtcweb-jsep-19.txt, lasting until March 24th, 2017.

Please raise issues you find with the draft on this list; if you prefer to use github, please let me or one of the other chairs know that you'd like us to move the issue to the list.

A major agenda item for us in Chicago will be working through any issues that the working group finds, and the chairs intend to forward the result to the IESG as soon as possible after the meeting.
Thanks for attention to this,
Ted, Sean, Cullen

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Mar 10, 2017 at 11:12 AM
Subject: I-D Action: draft-ietf-rtcweb-jsep-19.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft> directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Mar 2017 09:00:02 -0700

Just to follow up on this, I believe Christer's pull request to move
Appendix B into Bundle would resolve.  As we've noted in the past, we would
like to have the working group agree on the elements of Appendix B, so that
there is no confusion between rtcweb and mmusic on the needs of rtcweb.
The final approval and the doc, however, will belong to mmusic.

regards,

Ted

On Sat, Mar 11, 2017 at 6:57 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> Version -19 still contains Appendix B, which is still work in progress -
> and I am not only referring to the ondoing BYE/ssrc discussion, but the
> whole RTP-to-m-line mapping issue.
>
>
>
> So, if you want to issue WGLC, shouldn’t we remove Appendix B first (as it
> is anyway intended to be moved to BUNDLE)?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Ted Hardie
> *Sent:* 10 March 2017 21:22
> *To:* [email-masked]; Sean Turner <[email-masked]>; Cullen Jennings <
> [email-masked]>
> *Subject:* [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt
>
>
>
> Dear working group,
>
> This institutes a working group last call on
> draft-ietf-rtcweb-jsep-19.txt, lasting until March 24th, 2017.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Mar 2017 11:49:21 +0100

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
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Mar 2017 14:23:02 +0100

Hi,

I have reviewed the changes in the JSEP-19 document. For Appendix B see 
separate email.

1. The deleting of the "implementation requirements" (previously in 
5.1.1) makes me wonder if the "usage requirements" and specifically the 
bullets in the current 5.1.1 is actually needed. What I can see this is 
a 2119 normative rehashing of requirements that already exist elsewhere 
in the RTCWeb document suite.

    All session descriptions handled by JSEP implementations, both local
    and remote, MUST indicate support for the following specifications.
    If any of these are absent, this omission MUST be treated as an
    error.

The above actually make some sense to ensure that these features are 
negotiated.

    o  ICE, as specified in [RFC5245], MUST be used.  Note that the
       remote endpoint may use a Lite implementation; implementations
       MUST properly handle remote endpoints which do ICE-Lite.

Transport specification does not mandate use of ICE, only support. But, 
the MUST be used in this paragraph, appears to be unnecessary. This due 
the above paragraph. Which results in either a received offer indicates 
ICE or one rejects it, and one must include it in those one offers. 
Which will result in usage.

But, I don't think it actually is JSEP's role to mandate use of other 
than how the "signalling" element in the API surface is to be treated.

    o  DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as
       appropriate for the media type, as specified in
       [I-D.ietf-rtcweb-security-arch]

This is also double specification in the "MUST be used" as that is clear 
from the sec-arch document in section 5.5. that it must be used.

    The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as
    discussed in [I-D.ietf-rtcweb-security-arch].

Also covered in Section 5.5. of Sec-ARCH.

2. Section 5.1.2:

    o  The profile in any "m=" line in any answer MUST exactly match the
       profile provided in the offer.

    o  Any profile matching the following patterns MUST be accepted:
       "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]"

These two are in conflict in cases when the answer to an 
"UDP/TLS/RTP/SAVPF" offer comes back as UDP/TLS/RTP/SAVP. Then the first 
can't be fulfilled, but the second is. Isn't the rule "It either is an 
exact match or matches the following patterns"?

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Mar 2017 08:17:22 -0700

On Fri, Mar 24, 2017 at 6:23 AM, Magnus Westerlund <
[email-masked]> wrote:

> 1. The deleting of the "implementation requirements" (previously in 5.1.1)
> makes me wonder if the "usage requirements" and specifically the bullets in
> the current 5.1.1 is actually needed. What I can see this is a 2119
> normative rehashing of requirements that already exist elsewhere in the
> RTCWeb document suite.
>
> the MUST be used in this paragraph, appears to be unnecessary. This due the
> above paragraph. Which results in either a received offer indicates ICE or
> one rejects it, and one must include it in those one offers. Which will
> result in usage.
>
> But, I don't think it actually is JSEP's role to mandate use of other than
> how the "signalling" element in the API surface is to be treated.
>
>

They are not in conflict. The first is about what you send. The second is
about what you accept.

-Ekr

> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Mar 2017 16:37:02 +0100

Den 2017-03-24 kl. 16:17, skrev Eric Rescorla:
>
>
> On Fri, Mar 24, 2017 at 6:23 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     2. Section 5.1.2:
>
>     "UDP/TLS/RTP/SAVPF" offer comes back as UDP/TLS/RTP/SAVP. Then the
>     first can't be fulfilled, but the second is. Isn't the rule "It
>     either is an exact match or matches the following patterns"?
>
>
> They are not in conflict. The first is about what you send. The second
> is about what you accept.
>

Ok, but the received vs send directionality is not at all clear in the 
first bullet. The accept in the second bullet, implies a received SDP. I 
would propose that the first bullet is ammended to include a "in any 
answer generated by the JSEP implementation MUST exactly ..." or similar.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 24 Mar 2017 11:52:56 -0700

PR welcome.

-Ekr

On Fri, Mar 24, 2017 at 8:37 AM, Magnus Westerlund <
[email-masked]> wrote:

> would propose that the first bullet is ammended to include a "in any answer
> generated by the JSEP implementation MUST exactly ..." or similar.
>
>
> Cheers
>
> Magnus Westerlund
>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 24 Mar 2017 21:46:06 +0000

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

https://github.com/rtcweb-wg/jsep/pull/627

https://github.com/rtcweb-wg/jsep/pull/628

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 <
[email-masked]> wrote:

> <+46%2010%20714%2082%2087>
> <+46%2073%20094%2090%2079>
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 26 Mar 2017 10:44:51 -0500

> Please take a look and see what you think.

See other thread and on these PRs.

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

Yes, that is what I required for being okay with this. And as I said, I 
accept that is looks like it does, but I would very much have preferred 
another way of expressing it, that is RTP stream centric.

> authors of future extensions can write their text in a way that works
> well with this algorithm if it's necessary.

Most likely, but there can clearly be cases which doesn't match existing 
patterns. And I think part of my issue here is there might exist an 
expectation that an RTP/RTCP extension also needs to update BUNDLE. 
Which I think is unfortunate.

Cheers

Magnus

>
> On Fri, Mar 24, 2017 at 3:49 AM Magnus Westerlund
>     <tel:+46%2010%20714%2082%2087>
>     <tel:+46%2073%20094%2090%2079>
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 26 Mar 2017 15:34:26 -0500

Hi,

I have created an PR:

https://github.com/rtcweb-wg/jsep/pull/629

Cheers

Magnus

Den 2017-03-24 kl. 13:52, skrev Eric Rescorla:
> PR welcome.
>
> -Ekr
>
>
> On Fri, Mar 24, 2017 at 8:37 AM, Magnus Westerlund
>         <[email-masked]
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         wrote:
>
>             2. Section 5.1.2:
>
>     Ok, but the received vs send directionality is not at all clear in
>     the first bullet. The accept in the second bullet, implies a
>     received SDP. I would propose that the first bullet is ammended to
>     include a "in any answer generated by the JSEP implementation MUST
>     exactly ..." or similar.
>
>
>     Cheers
>
>     Magnus Westerlund
>
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>

-- 

Magnus Westerlund