Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07

[Justin Uberti <[e-mail]>]

On Tue, Jul 22, 2014 at 7:56 PM, Christian Groves <
[e-mail]> wrote:

> The browser would delay the establishment of media that are part of the
> "a=group:clue" group until a CLUE exchange has taken place and those media
> have been selected via a CLUE configure message. I'm not sure if that fits
> your criteria for acting differently?
>
> The browser doesn't understand a=group:clue. How could it know that it
needs to wait for CLUE messaging to complete?



> On 21/07/2014 6:34 PM, Kevin Dempsey wrote:
>
>> Would the browser be expected to act differently with "a=group:clue"? If
>> not, then that is really part of the signalling and not part of the
>> createXxx/setXxxDescription interface.
>>
>> The SDP passed to setXxxDescription and the SDP sent as part of the
>> signalling (if SDP is used) do not need to be identical.
>>
>>
>> On 21 July 2014 03:35, Kiran Kumar Guduru <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     It seems there is a small mis-understanding here. I agree there is
>>     a need for parsing and editing SDP by JS application for now.
>>
>>     I am not saying that constraints will do everything.
>>
>>     My intention is, to find the possibilities to extend the API of
>>     existing RTCPeerConnection and proposed RTCRTPSender/Receiver to
>>     add the attributes required by JS application.
>>
>>     For now, I proposed solution for one such kind of problem, i.e.,
>>     prioritizing codecs.
>>
>>     setSdPAttribute (key, value) is just an example on top of my head,
>>     which might solve this. But we can really figure out this after
>>     getting the proposed API (RTCRTPSender/Receiver ) in draft.
>>
>>     Regards,
>>
>>     Kiran
>>
>>     ------- *Original Message* -------
>>
>>     *Sender* : Paul Kyzivat<[e-mail]
>>     <mailto:[e-mail]>>
>>
>>     *Date* : Jul 19, 2014 22:35 (GMT+09:00)
>>
>>     *Title* : Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>>
>>
>>     Kiran,
>>
>>
>>     My need won't be satisfied by plausible constraints.
>>     For instance, to interwork with CLUE it will be necessary to add an
>>     "a=group:clue" and include in it those m-lines that are to be "clue
>>     controlled". And that is needed in both offer and answer processing.
>>
>>     Thanks,
>>     Paul
>>
>>
>>     On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote:
>>     > Dear Paul,
>>     >
>>     > My comment is only regarding the comments on section 6 of the
>>     JSEP draft.
>>     >
>>     > The sdp mangling described in section 6 may result in various error
>>     > scenarios.
>>     >
>>     > In that section, it is described like most of the parameters can be
>>     > modified thorugh constraints.
>>     >
>>     > The required modification, I found, which cannot not be done by the
>>     > constraints is "Remove or reorder of codecs (m=)"
>>     >
>>     > In order to avoid the SDP mangling at Java Script application
>>     level, I
>>     > submitted a draft for changing the codec preferences
>>     > http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
>> .
>>     > (Please review it).
>>     >
>>     > If this proposal is acceptable to the group, I hope we can remove
>>     > section 6 from JSEP draft.
>>     >
>>     > (Expecting that we can find alternatives for adding extra attributes
>>     > like CLUE as identified by you, for example by extending the
>>     > proposed RTCRTPSender/Receiver by adding a generic
>>     setSdPAttribute (key,
>>     > value) method).
>>     >
>>     > Thanks,
>>     >
>>     > Kiran.
>>     >
>>     >
>>     >
>>     > -------Original Message--------
>>     > Sent: Paul Kyzivat
>>     > Date: Fri, 18 Jul 2014 14:32:24 -0400
>>     > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
>>     >
>>     > I just did my first thorough read-through of JSEP in quite some
>>     time. I
>>     > came away with a number of concerns:
>>     >
>>     > Section 1.1:
>>     >
>>     > When describing offers, modification by the application is
>>     mentioned:
>>     >
>>     >      JSEP's handling of session descriptions is simple and
>>     >      straightforward.  Whenever an offer/answer exchange is
>>     needed, the
>>     >      initiating side creates an offer by calling a createOffer()
>>     API.  The
>>     >      application *optionally modifies that offer*, and then uses
>>     it to set
>>     >      up its local config via the setLocalDescription() API.
>>     >
>>     > but when describing answers it is not:
>>     >
>>     >      When the call is accepted, the callee uses the
>>     createAnswer() API to
>>     >      generate an appropriate answer, applies it using
>>     >      setLocalDescription(), and sends the answer back to the
>>     initiator
>>     >      over the signaling channel.  When the offerer gets that
>>     answer, it
>>     >      installs it using setRemoteDescription(), and initial setup is
>>     >      complete.
>>     >
>>     > And Section 6 only talks about changing offers, not answers. It is
>>     > equally important to be able to modify answers. (More on this in
>>     later
>>     > comment on section 6.)
>>     >
>>     > Section 4.1.4:
>>     >
>>     >      The only difference between a provisional and final answer
>>     is that
>>     >      the final answer results in the freeing of any unused
>>     resources that
>>     >      were allocated as a result of the offer.  As such, the
>>     application
>>     >      can use some discretion on whether an answer should be
>>     applied as
>>     >      provisional or final, and can change the type of the session
>>     >      description as needed.  For example, in a serial forking
>>     scenario, an
>>     >      application may receive multiple "final" answers, one from each
>>     >      remote endpoint.  The application could choose to accept
>>     the initial
>>     >      answers as provisional answers, and only apply an answer as
>>     final
>>     >      when it receives one that meets its criteria (e.g. a live user
>>     >      instead of voicemail).
>>     >
>>     > Issue: in this forking case, until the final selection is made it is
>>     > unclear which one will need ICE completed. Only when a setlocal
>>     is done
>>     > on one of the answers will ICE begin to be performed. Then, if
>>     another
>>     > answer is provisionally set, won't that stop ICE for the prior
>>     one? And
>>     > won't it require new candidates? What if one of the earlier ones is
>>     > eventually chosen as final?
>>     >
>>     > And what if ICE completes for one of the candidates? Can't media
>>     start
>>     > to flow? Then what if a different candidate is set as the final
>>     answer?
>>     >
>>     > Section 4.1.4.1 <http://4.1.4.1>:
>>
>>     >
>>     > I question the following:
>>     >
>>     >      ...  While it is good practice to send an immediate
>>     >      response to an "offer", in order to warm up the session
>>     transport and
>>     >      prevent media clipping, the preferred handling for a web
>>     application
>>     >      would be to create and send an "inactive" final answer
>>     immediately
>>     >      after receiving the offer.  Later, when the called user
>>     actually
>>     >      accepts the call, the application can create a new
>>     "sendrecv" offer
>>     >      to update the previous offer/answer pair and start the
>>     media flow.
>>     >
>>     > This is very unfriendly when receiving calls that might be
>>     forked. By
>>     > immediately "answering" a call before knowing if the user will
>>     accept
>>     > it, you preempt the possibility that it will be answered on some
>>     other fork.
>>     >
>>     > For instance, if a call could come to your browser, or be sent to an
>>     > answering service, and your broswer is on but you aren't present to
>>     > accept the call, then the call will be accepted and then dropped
>>     rather
>>     > than sent to the answering machine.
>>     >
>>     > So this technique should not be used if there is any possibility
>>     that
>>     > the request could be coming from a source that might try other
>>     > possibilities.
>>     >
>>     > Section 5.2.1:
>>     >
>>     >      When createOffer is called for the first time, the result
>>     is known as
>>     >      the initial offer.
>>     >
>>     > By this definition, if a peer connection initially *received* an
>>     offer
>>     > and sent an answer, and then it later sends an offer then that offer
>>     > would be considered an initial offer.
>>     >
>>     > I think perhaps what is intended is:
>>     >
>>     >      When createOffer is called before setLocal has been called with
>>     >      an offer,  the result is known as the initial offer.
>>     >
>>     > The following doesn't support the "balanced" BUNDLE policy:
>>     >
>>     >      Once all m= sections have been generated, a session-level
>>     "a=group"
>>     >      attribute MUST be added as specified in [RFC5888].  This
>>     attribute
>>     >      MUST have semantics "BUNDLE", and MUST include the mid
>>     identifiers of
>>     >      each m= section.  The effect of this is that the browser
>>     offers all
>>     >      m= sections as one BUNDLE group.  However, whether the m=
>>     sections
>>     >      are bundle-only or not depends on the BUNDLE policy.
>>     >
>>     > Section 5.2.2 says:
>>     >
>>     >      o  If any MediaStreamTracks have been added, and there
>>     exist recvonly
>>     >         m= sections of the appropriate media type with no associated
>>     >         MediaStreamTracks, or rejected m= sections of any media
>>     type,
>>     >         those m= sections MUST be recycled, and a local
>>     MediaStreamTrack
>>     >         associated with these recycled m= sections until all
>>     such existing
>>     >         m= sections have been used.  This includes any recvonly or
>>     >         rejected m= sections created by the preceding paragraph.
>>     >
>>     > This fails to say anything about codec compatibility. SDP O/A
>>     requires
>>     > the answer to be a subset of the offer in terms of PT/codec
>>     > configuration. You should not use the same m-line unless there is a
>>     > desire to use the same settings for the new track as are
>>     currently in
>>     > use in the other direction.
>>     >
>>     > Section 5.3.1:
>>     >
>>     >      When createAnswer is called for the first time after a remote
>>     >      description has been provided, the result is known as the
>>     initial
>>     >      answer.
>>     >
>>     > By this definition, if a peer connection initially sent an offer and
>>     > received an answer, and then it later receives an offer then the
>>     answer
>>     > to that first *received* offer would be considered an Initial
>>     Answer.
>>     >
>>     > I think perhaps what is intended is:
>>     >
>>     >      When createAnswer is called before setLocal has been called
>>     with
>>     >      an offer,  the result is known as the initial answer.
>>     >
>>     > When specifying the mapping of local tracks to m-lines in a received
>>     > offer, there is again no discussion of codec compatibility. It
>>     is quite
>>     > possible that the m-line chosen by the algorithm in this section
>>     won't
>>     > have compatible codec attributes, but some other m-line will.
>>     >
>>     > Sections 5.3.2, 5.3.3, and 5.4-5.7:
>>     >
>>     > Are these empty because the content is yet to be written?
>>     >
>>     > Section 6:
>>     >
>>     > Other likely changes are addition of extra attributes and maybe
>>     other
>>     > parameters. For instance, CLUE will want to add another grouping
>>     construct.
>>     >
>>     > Thanks,
>>     > Paul
>>     >
>>     >
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>