profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ajeanmahoney/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jean Mahoney ajeanmahoney Plano, Texas

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.

ekr

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

ekr

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.

ekr

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?

ekr

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>
ekr

comment created time in 2 months

PR opened rtcweb-wg/jsep

Reviewers
Add Disclaimer as provided by Murray
+32 -1

0 comment

1 changed file

pr created time in 2 months

push eventrtcweb-wg/jsep

ekr

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>

view details

push time in 2 months

PR merged rtcweb-wg/jsep

Ekr review

This includes

  1. Removing my postal address. Mozilla closed that office.
  2. small editorial changes
  3. Removing bogus whitespace.
+33 -40

2 comments

1 changed file

ekr

pr closed time in 2 months

push eventrtcweb-wg/jsep

ekr

commit sha 60135f9c72208741012b115963977de8e680b1ad

SSRCs must be unique. Fixes #1011 (#1013)

view details

push time in 2 months

issue closedrtcweb-wg/jsep

Avoid SSRC collisions

 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

PR merged rtcweb-wg/jsep

SSRCs must be unique. Fixes #1011
+2 -2

0 comment

1 changed file

ekr

pr closed time in 2 months

push eventrtcweb-wg/jsep

ekr

commit sha 6d0a9d3c0870b07e126bcc4fb6d2771dbf1c386f

Clarify when checks start. Fixes #1010 (#1014)

view details

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

PR merged rtcweb-wg/jsep

Clarify when checks start. Fixes #1010
+2 -1

0 comment

1 changed file

ekr

pr closed time in 2 months

PR opened rtcweb-wg/jsep

Reviewers
Clarify when checks start. Fixes #1010
+2 -1

0 comment

1 changed file

pr created time in 2 months

PR opened rtcweb-wg/jsep

SSRCs must be unique. Fixes #1011
+2 -2

0 comment

1 changed file

pr created time in 2 months

pull request commentrtcweb-wg/jsep

Ekr review

@juberti I think I've got your changes and we are ready to land?

ekr

comment created time in 2 months

Pull request review commentrtcweb-wg/jsep

Ekr review

 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.

ekr

comment created time in 2 months

issue closedrtcweb-wg/jsep

Glare?

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

Glare?

Sold. Closing.

ekr

comment created time in 2 months

issue commentrtcweb-wg/jsep

Glare?

This text might be slightly redundant, but it's not wrong. I'd suggest keeping as-is.

ekr

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."

ekr

comment created time in 2 months

issue commentrtcweb-wg/jsep

Avoid SSRC collisions

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.

ekr

comment created time in 2 months

Pull request review commentrtcweb-wg/jsep

Ekr review

 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

ekr

comment created time in 2 months

Pull request review commentrtcweb-wg/jsep

Ekr review

 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
ekr

comment created time in 2 months

Pull request review commentrtcweb-wg/jsep

Ekr review

 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
ekr

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.

ekr

comment created time in 2 months

Pull request review commentrtcweb-wg/jsep

Ekr review

 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.

ekr

comment created time in 2 months

issue commentrtcweb-wg/jsep

Avoid SSRC collisions

Good question. @gloinul: ^^?

ekr

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."

ekr

comment created time in 2 months