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

Received on Wednesday, 15 February 2012 08:01:38 UTC