RE: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case

See below.



> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Christer Holmberg
> Sent: 16 February 2012 09:01
> To: Cullen Jennings
> Cc: rtcweb@ietf.org; public-webrtc@w3.org
> Subject: Re: [rtcweb] JSEP-02: SDP_PRANSWER and FEDEX use-case
> 
> 
> Hi,
> 
> (I changed the subject to JSEP-02)
> 
> >> Section 6.1.4 of jsep-01 says:
> >>
> >>         "SDP_PRANSWER indicates that a description should be parsed
> as an
> >>          answer, but not a final answer, and so should not result in
> the
> >>          starting of media transmission. A description used as a
> SDP_PRANSWER
> >>          may be applied as a response to a SDP_OFFER, or an update
> to a
> >>          previously sent SDP_PRANSWER."
> >>
> >>
> >> Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP
> answer received in a SIP 18x response is provided to the browser as a
> SDP_PRANSWER.
> >>
> >>
> >> Q1: Since SDP_PRANSWER is not supposed to start media transmission,
> how will the use-case work? As
> >> far as I know, media transmission is needed for the FEDEX use-case.
> >
> > Consider a browser A that implemented a protocol something like ROAP
> using the JSEP API so it is
> > going to a ROAP to SIP GW then then goes to a GW to the PSTN that
> calls 1-800 go fedex.
> >
> > The browser does a createOffer followed by setLocal with offer and
> sends the offer to the ROAP
> > to SIP GW which turns it into an INVITE with offer to the PSTN GW. At
> this point the browse is
> > listening to any media the PSTN GW might send. The PSTN GW sends 180
> with SDP  that gets mapped
> > back to a setRemote with SDP_PRANSWER. That allows the browser and GW
> to do ICE, DTLS , etc and
> > at this point the PSTN GW can start sending media to the browser.
> Given we just need 1 way media
> > at this point, not sure it matter much if browser sends any media or
> not. At the point the SIP 200
> > happens, that gets mapped to a final answer.
> 
> If we want unidirectional media, can't the same be achieved e.g. with
> SDP_ANSWER and a=recvonly?
> 
> (Also, in the FEDEX case, there could be scenarios where the browser
> does need to transit media, if the user is e.g. promted for DTMFs,
> voice commands etc...)
> 

[AndyH] - I agree that media transmission is required at this stage so that the user can navigate through voice prompts (E.g. via DTMF) I thought this was the main requirement from the FEDEX use case.


> 
> >> Q2: The draft doesn't really specify what SDP_PRANSWER is used for.
> I understand that it means
> >> that a "final" answer may be provided later, but it doesn't really
> say what the a browser would
> >> do with an SDP_PRANSWER - especially since it doesn't seem to enable
> media.
> >
> > I think the key thing is when the JS sets new SDP_OFFER in setLocal,
> it needs to be willing to
> > receive the old media and the media for the new SDP. A final answers
> means you not longer need
> > to to be able to receive the media for the old SDP. A provisional
> offer does not allow you stop
> > being able to receive the media for the old SDP.
> 
> That sounds very strange to me (and it's not described anywhere). In my
> opinoin - once an answer has been received, the browser starts using
> it, together with the associated offer.
> 
> Also, I don't see the need for your described behavior in the FEDEX
> case. Because, since the use-case takes place during session
> establishment, the most likely is no old SDP. So, you could as well use
> SDP_ANSWER, and when the call has been answered a new SDP_ANSWER.
> 
> 
> Regards,
> 
> Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

Received on Thursday, 16 February 2012 20:04:39 UTC