Re: [rtcweb] Agenda requests for Atlanta meeting

[James Polk <[e-mail]>]

At 12:43 PM 10/12/2012, Christer Holmberg wrote:
>Hi,
>
> > 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.
>
>As far as I know, UPDATE is allowed after a reliable 180. If you 
>don't agree, please show me the text which forbids it :)

UPDATE is allowed after a before and after a 180, and allowed after a 
200 OK to the INVITE. RFC 6442 (Geolocation Header) took advantage of 
this function through/with/by/whatever the blessing of Jonathan R.

James


>Regards,
>
>Christer
>
>
>
>On Oct 10, 2012, at 1:51 PM, Parthasarathi R 
><[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Cullen Jennings (fluffy)
> > Sent: Wednesday, October 10, 2012 1:35 AM
> > To: Christer Holmberg
> > Cc: [e-mail]
> > Subject: Re: [rtcweb] Agenda requests for Atlanta meeting
> >
> >
> > On Oct 9, 2012, at 12:04 , Christer Holmberg
> > <[e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb