bacampbe/draft-campbell-art-rfc5727-update 0
Update to RFC5727
josephlhall/IASA2-wrkshp-report 0
The workshop report for the IETF IASA 2.0 virtual workshop sessions in February 2017.
Pull request review commentrtcweb-wg/jsep
Add Disclaimer as provided by Murray
example. Providing createOffer/createAnswer avoids this problem.</t> </section>+ <section anchor="sec.disclaimer" numbered="true" toc="default">+ <name>Contradiction Regarding Bundle-only "m=" Sections</name>
Based on the discussion, seems like my suggestion should be reverted.
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
Add Disclaimer as provided by Murray
example. Providing createOffer/createAnswer avoids this problem.</t> </section>+ <section anchor="sec.disclaimer" numbered="true" toc="default">+ <name>Contradiction regarding bundle-only "m=" sections</name>+ <t>+ Since the approval of the WebRTC specification documents, the+ IETF has become aware of an inconsistency between the document+ specifying JSEP and the document specifying BUNDLE ([rfced: This RFC],+ and <xref target="RFC8843" format="default"/> respectively)+ Rather than delaying publication further to come+ to a resolution, the documents are being published as they were+ originally approved. The IETF intends to restart work on these+ technologies, and revised versions of these documents will be+ published as soon as a resolution becomes available.+ </t>+ <t>+ The specific issue involves the handling of "m=" sections that+ are designated as bundle-only, as discussed in [rfced: This RFC], Section
@mskucherawy
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
Add Disclaimer as provided by Murray
example. Providing createOffer/createAnswer avoids this problem.</t> </section>+ <section anchor="sec.disclaimer" numbered="true" toc="default">+ <name>Contradiction regarding bundle-only "m=" sections</name>+ <t>+ Since the approval of the WebRTC specification documents, the+ IETF has become aware of an inconsistency between the document+ specifying JSEP and the document specifying BUNDLE ([rfced: This RFC],+ and <xref target="RFC8843" format="default"/> respectively)+ Rather than delaying publication further to come+ to a resolution, the documents are being published as they were+ originally approved. The IETF intends to restart work on these+ technologies, and revised versions of these documents will be+ published as soon as a resolution becomes available.+ </t>+ <t>+ The specific issue involves the handling of "m=" sections that+ are designated as bundle-only, as discussed in [rfced: This RFC], Section
Fine by me, but I will defer to Murray.
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
Add Disclaimer as provided by Murray
example. Providing createOffer/createAnswer avoids this problem.</t> </section>+ <section anchor="sec.disclaimer" numbered="true" toc="default">+ <name>Contradiction regarding bundle-only "m=" sections</name>+ <t>+ Since the approval of the WebRTC specification documents, the+ IETF has become aware of an inconsistency between the document+ specifying JSEP and the document specifying BUNDLE ([rfced: This RFC],+ and <xref target="RFC8843" format="default"/> respectively)+ Rather than delaying publication further to come+ to a resolution, the documents are being published as they were+ originally approved. The IETF intends to restart work on these+ technologies, and revised versions of these documents will be+ published as soon as a resolution becomes available.+ </t>+ <t>+ The specific issue involves the handling of "m=" sections that+ are designated as bundle-only, as discussed in [rfced: This RFC], Section
should this be an xref?
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
Add Disclaimer as provided by Murray
example. Providing createOffer/createAnswer avoids this problem.</t> </section>+ <section anchor="sec.disclaimer" numbered="true" toc="default">+ <name>Contradiction regarding bundle-only "m=" sections</name>
Should this be in caps, like the other headings? @ajeanmahoney
<name>Contradiction Regarding Bundle-only "m=" Sections</name>
comment created time in 2 months
PR opened rtcweb-wg/jsep
pr created time in 2 months
push eventrtcweb-wg/jsep
commit sha c341d3fa478261853d8e142b8c4e589ce0ecc8bc
Ekr review (#1012) * Remove EKR postal * Clarify sentence * Some more editorial * Justin's comments * Update draft-ietf-rtcweb-jsep.xml Co-authored-by: Justin Uberti <justin@uberti.name> * Update draft-ietf-rtcweb-jsep.xml Co-authored-by: Justin Uberti <justin@uberti.name> Co-authored-by: Justin Uberti <justin@uberti.name>
push time in 2 months
PR merged rtcweb-wg/jsep
This includes
- Removing my postal address. Mozilla closed that office.
- small editorial changes
- Removing bogus whitespace.
pr closed time in 2 months
push eventrtcweb-wg/jsep
commit sha 60135f9c72208741012b115963977de8e680b1ad
SSRCs must be unique. Fixes #1011 (#1013)
push time in 2 months
issue closedrtcweb-wg/jsep
If
an SSRC has not already been chosen for this outgoing RTP
stream, choose a random one. If media is already being
transmitted, the same SSRC SHOULD be used unless the clock rate
of the new codec is different, in which case a new SSRC MUST be
chosen, as specified in [RFC7160], Section 3.1.
Should the advice to choose a random SSRC ensure that there are no collisions?
closed time in 2 months
ekr
push eventrtcweb-wg/jsep
commit sha 6d0a9d3c0870b07e126bcc4fb6d2771dbf1c386f
Clarify when checks start. Fixes #1010 (#1014)
push time in 2 months
issue closedrtcweb-wg/jsep
can addIceCandidate be sent prior to setLD()
Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent. In the case of a new remote candidate, connectivity checks will be sent to the new candidate.
However, if you do this prior to setLD() this will not cause connectivity checks to be sent, right?
closed time in 2 months
ekr
pull request commentrtcweb-wg/jsep
@juberti I think I've got your changes and we are ready to land?
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host ]]></sourcecode> contains an SDP answer per <xref target="RFC3264" format="default"/> with the supported configuration for the session that is compatible with the parameters supplied in the most recent call to- setRemoteDescription, which <bcp14>MUST</bcp14> have been called prior to- calling createAnswer. Like createOffer, the returned blob+ setRemoteDescription (setRemoteDescription <bcp14>MUST</bcp14> have been called prior to
LGTM.
comment created time in 2 months
issue closedrtcweb-wg/jsep
If (1) setRemoteDescription was previously called with an offer, (2) setLocalDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, this will result in the starting of media transmission.
Point (2) seems a bit odd here. If you call it with an offer, then that's an error, right?
closed time in 2 months
ekr
issue commentrtcweb-wg/jsep
This text might be slightly redundant, but it's not wrong. I'd suggest keeping as-is.
comment created time in 2 months
issue commentrtcweb-wg/jsep
can addIceCandidate be sent prior to setLD()
maybe just add ", assuming setLocalDescription has already been called to initialize the ICE gathering process."
comment created time in 2 months
issue commentrtcweb-wg/jsep
I looked at RFC 3550 and the text there is mostly around handling collisions that occur in the multicast case, so I'd suggest just saying that the SSRC must be random and unique.
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host ]]></sourcecode> contains an SDP answer per <xref target="RFC3264" format="default"/> with the supported configuration for the session that is compatible with the parameters supplied in the most recent call to- setRemoteDescription, which <bcp14>MUST</bcp14> have been called prior to- calling createAnswer. Like createOffer, the returned blob+ setRemoteDescription (setRemoteDescription <bcp14>MUST</bcp14> have been called prior to
PTAL at my suggestion of a semicolon
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host ]]></sourcecode> contains an SDP answer per <xref target="RFC3264" format="default"/> with the supported configuration for the session that is compatible with the parameters supplied in the most recent call to- setRemoteDescription, which <bcp14>MUST</bcp14> have been called prior to- calling createAnswer. Like createOffer, the returned blob+ setRemoteDescription (setRemoteDescription <bcp14>MUST</bcp14> have been called prior to+ calling createAnswer.) Like createOffer, the returned blob
calling createAnswer. Like createOffer, the returned blob
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host ]]></sourcecode> contains an SDP answer per <xref target="RFC3264" format="default"/> with the supported configuration for the session that is compatible with the parameters supplied in the most recent call to- setRemoteDescription, which <bcp14>MUST</bcp14> have been called prior to- calling createAnswer. Like createOffer, the returned blob+ setRemoteDescription (setRemoteDescription <bcp14>MUST</bcp14> have been called prior to
setRemoteDescription; setRemoteDescription <bcp14>MUST</bcp14> have been called prior to
comment created time in 2 months
issue commentrtcweb-wg/jsep
can addIceCandidate be sent prior to setLD()
Something like that seems like a good idea. It won't always be setLD with an answer though.
comment created time in 2 months
Pull request review commentrtcweb-wg/jsep
candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host ]]></sourcecode> contains an SDP answer per <xref target="RFC3264" format="default"/> with the supported configuration for the session that is compatible with the parameters supplied in the most recent call to- setRemoteDescription, which <bcp14>MUST</bcp14> have been called prior to- calling createAnswer. Like createOffer, the returned blob+ setRemoteDescription (setRemoteDescription <bcp14>MUST</bcp14> have been called prior to
I am also not crazy about the parenthetical. If we can't improve it, I'm OK with it as-is.
comment created time in 2 months
issue commentrtcweb-wg/jsep
can addIceCandidate be sent prior to setLD()
Do you think we should change the text to say that? Perhaps "In the case of a new remote candidate, connectivity checks will be sent to the new candidate as soon as setLD(answer) is called, or immediately if it has been called already."
comment created time in 2 months