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

[Paul Kyzivat <[e-mail]>]

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