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

On Feb 17, 2012, at 1:33 AM, 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.
>> 	
>> 
>> 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)

I think I tired to cover this in some of my slides before. You end up with this problem if you map the 180 to a final answer, then when the 200 comes along, it is less clear what to do with it. If you map it to offer, then it's unclear how to handle the answer that comes in response to it. I think I had some slides that showed this at one point. Basically, I don't see how using using an answer will work. The issue is not if you are sending or receiving one way media, the issue is when you can free resources allocated in the offer but not needed in the answer.

Received on Friday, 17 February 2012 21:19:27 UTC