Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case

Answering for the the -02 version of jsep …


On Feb 15, 2012, at 2:47 , Christer Holmberg wrote:

>  
> Hi,
>  
> 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.

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

>  
> Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), is there a need for SDP_PRANSWER?

> 
> Regards,
>  
> Christer
>  
>  
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

Received on Thursday, 16 February 2012 06:41:01 UTC