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

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.
>	
>
> I think this is just me being unclear. When I say "start media transmission", I mean that when the browser gets a SDP_PRANSWER 
> in response to an offer, the browser will not start transmitting media. However, it will play out any media that is received 
> after the offer is installed, and the gateway can start sending media at any time after it gets the offer.

Again, you could achieve that using SDP_ANSWER and a direction attribute (a=recvonly). I don't think we need SDP_PRANSWER for unidirectional media purpose.

(And, as was mentioned, there may actually be a need to also transmit media for the FEDEX 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.
>	
>
> SDP_PRANSWER allows, among other things, the callee's ICE and SRTP info to be provided so that early media can 
> be received by the caller. I think it should make more sense given my answer to #1.

As I replied to #1, I don't think we need SDP_PRANSWER to establish unidirectional media, so I would like to know what those "other things" are :)

		 
>> Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread), is there a need for SDP_PRANSWER?
>	
>
> SDP_PRANSWER has slightly different semantics in that it is not intended to indicate consent by the callee, whereas SDP_ANSWER does. 

What does the browser do with that information?

My understanding was that the browser is going to use media plane mechanisms (e.g. ICE) for callee consent.

Regards,

Christer

Received on Friday, 17 February 2012 08:34:34 UTC