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

Cullen,

Real case would be anything which implements small group calling with
caller side mixing.

One example, which is typically used, is a sports team contact. There is a
SIP URL which is associated with an entire team. A person places a call to
the team's SIP URL. Call gets forked to all the members of the team. Some
members answer the call. Multiple simultaneous calls are established, with
mixing done in the caller user agent. All the team members who answered and
the caller are talking to each other.

Another example is shared line appearance. SIP URL which belongs to boss
calls both bosses and secretary phones. If both peak up, both are placed in
a conference (once again with mixing done in the client user agent). This
simulates two analog phones connected to the same line.

Before anybody starts saying that those examples are limited to traditional
telephony and have only a limited applicability, I would suggest to look at
GroupMe or a number of other group calling start ups that showed up and
managed to create quite a substantial following recently.

Two workaround exist to implement small group calling with no forking.

One option is to call through a conferencing server. Downside, apart from a
need for a conferencing server, is media hair-pin and extra delay on audio
path.

Another option is to send an invitation for a call to all potential
participants, get offers from each participant that is joining the call,
create new channel for each offer and send the answer back. Downside of
this approach is an extra half a round trip.

Both of those options become especially costly if most of the calls are to
one party only and only a small portion of calls result in group call.
_____________
Roman Shpount


On Fri, Feb 17, 2012 at 4:21 PM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> 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 <
> pravindran@sonusnet.com> 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; rtcweb@ietf.org; public-webrtc@w3.org
> > >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:fluffy@iii.ca]
> > >>Sent: Wednesday, February 15, 2012 1:31 PM
> > >>To: Ravindran, Parthasarathi
> > >>Cc: Justin Uberti; rtcweb@ietf.org; public-webrtc@w3.org
> > >>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:juberti@google.com]
> > >>> Sent: Tuesday, February 14, 2012 11:36 PM
> > >>> To: Ravindran, Parthasarathi
> > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> > >>> 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
> > >><pravindran@sonusnet.com> 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:juberti@google.com]
> > >>> Sent: Tuesday, February 14, 2012 9:47 PM
> > >>>
> > >>> To: Ravindran, Parthasarathi
> > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> > >>> 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
> > >><pravindran@sonusnet.com> 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:juberti@google.com]
> > >>> Sent: Tuesday, February 14, 2012 7:29 PM
> > >>> To: Ravindran, Parthasarathi
> > >>> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> > >>> 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
> > >><pravindran@sonusnet.com> 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'; rtcweb@ietf.org; public-webrtc@w3.org
> > >>> 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, answer1);
> > >>> OffererUA->Answerer1UA: <media>
> > >>> OffererJS->OffererUA:  pc.setRemoteDescription(SDP_ANSWER, 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > >>Behalf Of Justin Uberti
> > >>> Sent: Thursday, February 09, 2012 2:27 AM
> > >>> To: rtcweb@ietf.org; public-webrtc@w3.org
> > >>> 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
> > >>> rtcweb@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>