Re: [rtcweb] Agenda requests for Atlanta meeting

Cullen,

As signaling is moved to JS (application layer), Offer-answer in JSEP has to
be generic enough. The underlying assumption in PRANSWER state is that
webserver knows whether the received SDP from remote is PRANSWER or final
ANSWER. Unfortunately, Webserver may not able to tell whether the receive in
lot of real time deployment which is an open issue now. UPDATE offer after
18x answer from remote is the typical example where PRANSWER state breaks.
The real-time usage of SIP UPDATE offer is to update the existing answer in
18x in the same dialog. Early dialog UPDATE callflow is well deployment
because of PSTN remote ringback (18x) from media server and then UPDATE with
SDP to update the media information of remote endpoing and then, call
connect (200 ok) from actual endpoint. The same PSTN callflow shall be
achieved by serial forking as well. Please note that the final answer or not
is not based on browser or originating SIP UA but it is based on the
intermediate SIP entities. 

>From RTCWeb perspective, The new OFFER is possible to be received in browser
as per RFC 3264 after the first answer is received. PRANSWER is the new
state in JSEP wherein JSEP is the extension of RFC 3264. It will be good in
case you explain how browser in PRANSWER has to handle new OFFER from the
remote side. 

Please include me in case any phone discussion if you are planning.

Thanks
Partha

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Cullen Jennings (fluffy)
Sent: Wednesday, October 10, 2012 1:35 AM
To: Christer Holmberg
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Agenda requests for Atlanta meeting

On Oct 9, 2012, at 12:04 , Christer Holmberg
<christer.holmberg@ericsson.com>
 wrote:

> Hi,
> 
>>> I have not seen any reason to relax 3264 yet but if something comes up,
agree we should carefully look at the cases. I think we can just do straight
up 3264.
>> 
>> RFC 3264 doesn't describe PRANSWER.  The concept is entirely absent.
>> 
>>  The offerer MAY immediately cease listening for media formats that
>>  were listed in the initial offer, but not present in the answer.
>> 
>> "the" answer.
> 
> I agree with Martin. 3264 O/A is always per dialog, and forking is
supported by generating multiple dialogs. JSEP, OTOH, in order to support
forking with a single "dialog" (peerConnection local descriptor), now
defines O/A as offer+any number of pranswers + answer.
> 
> So, we would e.g. have to define what happens if a new offer is received
from the remote side while the browser is in pranswer-received state (see my
call flow in another reply).

3264, SDP, 3261, and related documents are dealing with a bunch of things
including what happens at media plane and signaling plane. 

I'll note that though O/A is per dialog, there is only one O shared across
multiple legs and when you create the O you don't know how many dialogs
there will be. So from the media point of view (covered more in SDP spec
than 3264) there is one O with a bunch of A. From signaling point of view
there are a bunch of O/A pairs). 

The dialog is SIP signaling concept not a media plane level concept. We
moved the signaling part out of the browser and into the JS. But the media
part is still in the browser. So as 3264 says, after the offer is
constructed, we have to be willing to receive media for all the codec type
in the offer. When we get the answer 3264 makes it clear that one MAY stop
receiving the codecs that were in the offer but not selected in the answer.
However, this can not be done until the signaling layer is sure that no more
offers will be honored. Since that signalling part of Offer/Answer is in the
JS, the API need to to have a way to signal what the MAY part should do and
that is the PRANSWER vs ANSWER. 

People keep trying to make this some complex weird argument invoking the SIP
deities of the past and quoting incomprehensible phrases from various RFC
caved in stone but the bottom line in the code is very simple to understand.
When creating the offer you alloced some resources ( like a port to receive
video on ). When you get an answer that does not use that resource, you need
to tell the media stack if it should free the resources or not. O/A has
situation where you need to keep the resources available (like there are
more dialogs coming) and situation where you need to free the resource.
Since we split the signalling out of the browser and left the media in the
browser, we need be able to allow the JS that is dealing with signaling to
tell the browser when to free the resource. 

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb