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