Re: [rtcweb] Single offer with multiple answer handling in JSEP [was RE: New JSEP draft posted]

[Justin Uberti <[e-mail]>]

Partha,

Thanks for these example flows. I'm out on vacation this week but will try
to distill and incorporate the consensus on this topic when I return.

Regards,
--justin

On Sun, Feb 19, 2012 at 2:25 PM, Ravindran, Parthasarathi <
[e-mail]> wrote:

> Cullen,
>
> As I mentioned below, the problem statement is for multiple answer and
> multiple 200 is one of the IETF SIP (RFC 3261) defined multiple answer
> usecase. Deployed (real) SIP world usecase for multiple answer exists in
> form of 18x with answer1 and 2xx with answer2 for INVITE offer. I
> worked/interoped with multiple well deployed implementation which supports
> "receiving" multiple answer with slight different variance (and no UPDATE
> [RFC 3311] in the middle) and I'm sure more implementation exists. The
> reason for allowing "receiving" multiple answer is leniency while receiving
> the SIP message which is generally accepted in Product development. Even
> though some of the deployed implementation violates RFC 3264 for the noble
> reason of reducing the number of SIP messages (no UPDATE Offer/answer
> transaction after 18x) for the basic call, it is possible to make those
> implementation SIP RFC compliance by changing 18x To-Tag, Please look into
> "18x with SDP and 2xx with different SDP & To Tag" attachment for more
> details.
>
> Also, 18x with SDP and 2xx without SDP is the another set implementation
> exists as mentioned in "18x with SDP and 2xx without SDP" attachment. In
> case these details are not enough, I'll add Multiple 18x with different 2xx
> callflow later.
>
> Keeping aside SIP deployment, I'm still not convinced why browser MUST be
> restricted from multiple answer as I didn't see the technical reason for
> restricting. As I mentioned, Fixed-Mobile application is possible to
> implement using this mechanism and WebRTC shall provide the building block
> for it.  The callflow is shown in "Single Offer Multiple Answer callflow"
> example.
>
> AFAIK, offer results in RTP port allocation in the resource manager and
> SRTP key generation. In case first answer is received, those resources are
> required irrespective of multiple answer will receive or not. In case your
> argument is about pre-allocated (RSVP kind of) bandwidth for offer, those
> specific WebRTC applications are free to reject the second answer onwards
> and consider first answer as the final answer, so this proposal in not
> limiting those applications.  Could you please clarify any other list of
> resources lock/leak in your mind due to offer for my understanding. I'm
> asking this query as I get the feeling from other mail threads that
> resource lock/leak is one of the reason for requesting final answer by you.
>
> Justin,
>
> I have added 3 callflow as a starting point for the discussion which shall
> be added later in case consensus is reached. I'll provide multiple 18x with
> different order 2xx later.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Cullen Jennings [mailto:[e-mail]]
> >Sent: Saturday, February 18, 2012 2:51 AM
> >To: Justin Uberti
> >Cc: Ravindran, Parthasarathi; [e-mail]; [e-mail]
> >Subject: Re: [rtcweb] Single offer with multiple answer handling in JSEP
> >[was RE: New JSEP draft posted]
> >
> >
> >I'm most interested in real world use cases which if they were being
> >done with SIP would result in multiple 200 being processed by the
> >browser. I have not got my head around why this would be needed yet and
> >without the use cases I'm having a hard time deciding if there is a
> >problem or not.
> >
> >
> >On Feb 16, 2012, at 7:35 PM, Justin Uberti wrote:
> >
> >> Agree it has not been addressed. I'm having some trouble understanding
> >the exact flows that we need to address here (multiple 2xx, multiple 18x
> >followed by 2xx, multiple 18x followed by multiple 2xx) but if I
> >understand correctly your suggestion was:
> >>
> >> 1) allow a setRemoteDesc(SDP_ANSWER) to follow a
> >> setRemoteDesc(SDP_ANSWER)
> >> 2) document that in this case (multiple 2xx), the JS is responsible
> >for sending BYE to the previous answerer.
> >>
> >> which sounds totally reasonable to me.
> >>
> >> If this sounds good to you, would you mind sketching out a call flow
> >that I could include in the examples section?
> >>
> >> On Thu, Feb 16, 2012 at 2:11 AM, Ravindran, Parthasarathi
> ><[e-mail]> wrote:
> >> Cullen/Justin,
> >>
> >> Single offer with multiple answer open item is not addressed in -02
> >version of JSEP draft. Hope you first agree this as an open item in
> >JSEP.
> >>
> >> Thanks
> >> Partha
> >>
> >> >-----Original Message-----
> >> >From: Ravindran, Parthasarathi
> >> >Sent: Wednesday, February 15, 2012 2:43 PM
> >> >To: 'Cullen Jennings'
> >> >Cc: Justin Uberti; [e-mail]; [e-mail]
> >> >Subject: RE: [rtcweb] Single offer with multiple answer handling in
> >> >JSEP [was RE: New JSEP draft posted]
> >> >
> >> >Cullen,
> >> >
> >> >RFC3261 references for receiving multiple 2xx in UAC which does not
> >> >fork INVITE are as follows:
> >> >
> >> ><RFC quote>
> >> >Sec 13.1 Para 3:
> >> >
> >> >Therefore, when multiple 2xx responses are received from different
> >> >remote UAs (because the INVITE forked), each 2xx establishes a
> >> >different dialog.  All these dialogs are part of the same call.
> >> >
> >> >Sec 13.2.2.4 2xx Responses
> >> >
> >> >   Multiple 2xx responses may arrive at the UAC for a single INVITE
> >> >   request due to a forking proxy.  Each response is distinguished by
> >> >   the tag parameter in the To header field, and each represents a
> >> >   distinct dialog, with a distinct dialog identifier.
> >> >
> >> >   If, after acknowledging any 2xx response to an INVITE, the UAC
> >does
> >> >   not want to continue with that dialog, then the UAC MUST terminate
> >> >   the dialog by sending a BYE request as described in Section 15.
> >> ></RFC quote>
> >> >
> >> >As per the last statements, it is upto the SIP application to decide
> >> >which one of the final 2xx response has to be included within the
> >call.
> >> >The usecase 3 is based on RFC3262 (PRACK) support wherein it is
> >> >possible to receive multiple forked 18x with SDP followed by 2xx with
> >> >or without SDP and SIP 2xx response is not tied to offer/answer
> >exchange.
> >> >
> >> >I have provided mobile to desktop as an example to justify the last
> >> >answer may be used in the offer in some JS application. As I
> >> >mentioned below, there is no need to restrict updating latest answer
> >> >for an offer in terms of API and protocol.
> >> >
> >> >Thanks
> >> >Partha
> >> >
> >> >>-----Original Message-----
> >> >>From: Cullen Jennings [mailto:[e-mail]]
> >> >>Sent: Wednesday, February 15, 2012 1:31 PM
> >> >>To: Ravindran, Parthasarathi
> >> >>Cc: Justin Uberti; [e-mail]; [e-mail]
> >> >>Subject: Re: [rtcweb] Single offer with multiple answer handling in
> >> >>JSEP [was RE: New JSEP draft posted]
> >> >>
> >> >>
> >> >>I'm a bit lost on use case in SIP context - assuming that the UAC
> >> >>did not fork but that a proxy or B2BUA did the forking, it seems
> >> >>like the UAC should never receive more than one final response.
> >> >>
> >> >>In the case of moving from desktop to mobile, it seems like that is
> >> >>updating the stream and would use a call flow more like update
> >> >>examples in the draft instead of trying to reuse some old answer.
> >> >>
> >> >>
> >> >>On Feb 14, 2012, at 11:24 , Ravindran, Parthasarathi wrote:
> >> >>
> >> >>> Justin,
> >> >>>
> >> >>> Some of the usecases could be
> >> >>> 1)      The same user of a website signed-in in the multiples
> >devices
> >> >>and acts as answerer,  the session establishment request to the
> >> >>identity will alert all the signed-in devices and it is possible
> >> >>that multiple devices answer to the session. Here, user may move
> >> >>from one device
> >> >>(mobile) to another device (desktop) within the session and wishes
> >> >>to continue the session with the last answer. Please note that
> >> >>website is flexible to provide this service.
> >> >>> 2)      RFC 3261 SIP UA offer/answer handling w.r.t INVITE with
> >SDP
> >> >to
> >> >>multiple 2xx with SDP handling scenario using JSEP
> >> >>> 3)      Another SIP usecase could be multiple 18x responses with
> >SDP
> >> >>for INVITE with SDP and multiple 2xx responses without SDP but order
> >> >>within 18x and 200 are not same. Say 2xx of the second 18x is
> >> >>received as the first 2xx. Here, we need to know how second 18x is
> >> >>handled and also, the subsequent 2xx is handled.
> >> >>>
> >> >>> Of course, it is possible to build more usecases around this area.
> >> >>> As
> >> >>we made signaling outside the scope of WebRTC, it is upto JS
> >> >>application to decide the order in which offer/answer happens. I'm
> >> >>not relating offer/answer FSM with session establishment state like
> >> >>18x, 2xx but I'm interested in knowing browser media plane behavior
> >> >>in different state of offer/answer handling by which JS application
> >> >>behaves consistently in all browsers.
> >> >>>
> >> >>> Thanks
> >> >>> Partha
> >> >>>
> >> >>>
> >> >>> From: Justin Uberti [mailto:[e-mail]]
> >> >>> Sent: Tuesday, February 14, 2012 11:36 PM
> >> >>> To: Ravindran, Parthasarathi
> >> >>> Cc: [e-mail]; [e-mail]
> >> >>> Subject: Re: Single offer with multiple answer handling in JSEP
> >> >>> [was
> >> >>RE: [rtcweb] New JSEP draft posted]
> >> >>>
> >> >>> Partha,
> >> >>>
> >> >>> I need more information about the use case to provide an accurate
> >> >>response. As mentioned in my earlier mail, are both answers 2xx
> >> >>responses?
> >> >>>
> >> >>> On Tue, Feb 14, 2012 at 12:17 PM, Ravindran, Parthasarathi
> >> >><[e-mail]> wrote:
> >> >>> Hi Justin,
> >> >>>
> >> >>> In this mail thread, Let us define the behavior of multiple
> >> >>> (atleast
> >> >>two) answers for the single offer in WebRTC browser.  Now, Please
> >> >>let me know your opinion for my below mail.
> >> >>>
> >> >>> Thanks
> >> >>> Partha
> >> >>>
> >> >>> From: Justin Uberti [mailto:[e-mail]]
> >> >>> Sent: Tuesday, February 14, 2012 9:47 PM
> >> >>>
> >> >>> To: Ravindran, Parthasarathi
> >> >>> Cc: [e-mail]; [e-mail]
> >> >>> Subject: Re: Single offer with multiple answer handling in JSEP
> >> >>> [was
> >> >>RE: [rtcweb] New JSEP draft posted]
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Tue, Feb 14, 2012 at 6:39 AM, Ravindran, Parthasarathi
> >> >><[e-mail]> wrote:
> >> >>> Hi Justin,
> >> >>>
> >> >>> It will be good to mention in the JSEP draft  that multiple
> >> >>> answers
> >> >>for single offer will not lead to RTP Mixing and WebRTC client acts
> >> >>as RTP Endpoint.
> >> >>>
> >> >>> Failing the second Answer will be limiting the provision in RFC
> >> >>> 3264
> >> >>offer/answer itself as RFC 3264 supports single offer with multiple
> >> >>answer. Also, it is better to define the behavior in API rather than
> >> >>putting this scenario in the browser implementation specific. In
> >> >>simple scenarios (like alerting with one answer, connect with second
> >> >>answer), replacing the previous ANSWER will be expected behavior.
> >> >>This may not be desired behavior in case two connect responses from
> >> >>different WebRTC clients received with different answers  but there
> >> >>is no other alternative solution possible without mixing.
> >> >>>
> >> >>> Do you need to support 2 final answers, or would the provisional
> >> >>answer support provided via SDP_PRANSWER work for you?
> >> >>>
> >> >>> IMO, it is better to define it explicitly in JSEP that "latest
> >> >>> ANSWER
> >> >>to the offer will replace the existing answer is the expected
> >> >>behavior ". Also, Please mentioned that JS application is
> >responsible for
> >> >>discarding (terminating) previous ANSWER notification.   Please let
> >me
> >> >>your opinion on this closure.
> >> >>>
> >> >>> Thanks
> >> >>> Partha
> >> >>>
> >> >>> From: Justin Uberti [mailto:[e-mail]]
> >> >>> Sent: Tuesday, February 14, 2012 7:29 PM
> >> >>> To: Ravindran, Parthasarathi
> >> >>> Cc: [e-mail]; [e-mail]
> >> >>> Subject: Re: Single offer with multiple answer handling in JSEP
> >> >>> [was
> >> >>RE: [rtcweb] New JSEP draft posted]
> >> >>>
> >> >>> Regarding your previous mail, an ANSWER after an ANSWER would
> >> >>> either
> >> >>fail (if we wanted to simplify), or replace the previous ANSWER
> >> >>(essentially the same as if you had done setLocalDescription(OFFER,
> >> >>localDescription) followed by setRemoteDescription(ANSWER, answer2).
> >> >>>
> >> >>> In no case would it mix the descriptions/media from both answers.
> >> >>>
> >> >>> Other comments inline below.
> >> >>>
> >> >>> On Tue, Feb 14, 2012 at 1:24 AM, Ravindran, Parthasarathi
> >> >><[e-mail]> wrote:
> >> >>> Hi Justin,
> >> >>>
> >> >>> Adding to my earlier mail, In case answer2 SDP is updated in
> >> >>> offerer1
> >> >>browser without notifying answerer1, then answer1 will continue to
> >> >>transmit RTP which may not be desired behavior. IMO, we need to
> >> >>define this behavior clearly in offerer side. Some of the possible
> >> >>solutions are
> >> >>>
> >> >>> 1)      offerer1 has to send atleast RTCP BYE packets towards
> >> >>answerer1 while accepting the answerer2 SDP.
> >> >>>
> >> >>> 2)      Throw callback to clear answer1 SDP towards offererJS.
> >> >>>
> >> >>>
> >> >>> The application which called setRemoteDescription twice should
> >> >>> have
> >> >>the best idea about what is going on, and therefore is responsible
> >> >>for notifying answerer1 that its answer has been discarded, if it
> >> >>makes sense to do so. No callback should be needed here.
> >> >>>
> >> >>>
> >> >>> Please let me know your opinion here.
> >> >>>
> >> >>> Thanks
> >> >>> Partha
> >> >>>
> >> >>> From: Ravindran, Parthasarathi
> >> >>> Sent: Tuesday, February 14, 2012 12:07 AM
> >> >>> To: 'Justin Uberti'; [e-mail]; [e-mail]
> >> >>> Subject: Single offer with multiple answer handling in JSEP [was
> >RE:
> >> >>[rtcweb] New JSEP draft posted]
> >> >>>
> >> >>> Hi Justin,
> >> >>>
> >> >>> In the draft, it is not spelled out explicitly what is the
> >> >>> expected
> >> >>behavior in offerer browser in case multiple answer is received for
> >> >>single offer. Offer/answer exchange in offerer is as follows:
> >> >>>
> >> >>> OffererJS->OffererUA: var offer = pc.createOffer(null);
> >> >>> OffererJS->OffererUA: pc.setLocalDescription(SDP_OFFER, offer);
> >> >>> OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER,
> >> >>> OffererJS->answer1);
> >> >>> OffererUA->Answerer1UA: <media>
> >> >>> OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER,
> >> >>> OffererJS->answer2);
> >> >>> OffererUA->Answerer?UA: <media>?
> >> >>>
> >> >>> My understanding is that "answer2" will update "answer1" in
> >> >>> browser
> >> >>and starting sending/receiving media towards answer2 media IP and
> >port.
> >> >>Could you please explain the expected behavior in offerer browser
> >> >>whether it updates the media stream based on the last answer or
> >> >>mixes both answerer.
> >> >>>
> >> >>> Thanks
> >> >>> Partha
> >> >>>
> >> >>> From: [e-mail] [mailto:[e-mail]] On
> >> >>Behalf Of Justin Uberti
> >> >>> Sent: Thursday, February 09, 2012 2:27 AM
> >> >>> To: [e-mail]; [e-mail]
> >> >>> Subject: [rtcweb] New JSEP draft posted
> >> >>>
> >> >>> Now available at http://www.ietf.org/id/draft-uberti-rtcweb-jsep-
> >> >>01.txt
> >> >>>
> >> >>> Includes changes based on implementation feedback, and I believe
> >> >>> it
> >> >>addresses most of the concerns raised in last week's interim
> >meetings:
> >> >>> - Initial documentation provided for each API call, and what state
> >> >>changes it causes
> >> >>> - More examples, including a complete basic sample application
> >> >>> - Simplified approach to trickle candidate handling
> >> >>> - Resolved concerns about how to separate SDP attributes into
> >> >>> media /
> >> >>transport
> >> >>> - Provided encapsulation for SDP blobs and ICE candidate lines, in
> >> >>> the
> >> >>event we want to change encodings or provide helper functions for JS
> >> >>> - Provided mechanism for limiting candidates to TURN-only
> >> >>> - Resolved several implementation issues
> >> >>>
> >> >>> I have not yet addressed the non-overlapping codec concern
> >> >>> mentioned
> >> >>in the interim meeting. I think there are ways of handling this
> >> >>either in the application or the implementation, but I wanted to get
> >> >>this -01 out first for feedback.
> >> >>>
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> rtcweb mailing list
> >> >>> [e-mail]
> >> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >>
>
>