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

["Ravindran, Parthasarathi" <[e-mail]>]

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