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