Re: [rtcweb] Agenda requests for Atlanta meeting

I fully agree this needs to work early media to PSTN via SIP. I don't see any problem with doing that. I'm happy to work through detail call flows to make sure that early media to PSTN works. 

Update after a 180 is not allowed by the Update RFC as I pointed out in other email exactly because just in SIP with no RTCP web, the UA that caret the invite would not have enough information to be able to process this as you point in the thread below. 

On Oct 10, 2012, at 1:51 PM, Parthasarathi R <partha@parthasarathi.co.in> wrote:

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