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

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

Received on Thursday, 16 February 2012 08:01:52 UTC