[rtcweb] Why SDP answer needs and ack … was Re: SDP Offer/Answer draft-jennings-rtcweb-signaling

[Cullen Jennings <[e-mail]>]

Hi - glad to hear you see this going the right direction. On the topic of why we have an OK, let me provide a bit of the motivation. 

When one side sends and answer that says it wants to receive VP8 instead of H.264, it's probably useful to know when the other side got that information. This might impact the timing of when o send things or user interface that provides feedback about the status of the other side. We are also dealing with a web transaction model where transaction are not guarantee to happen even if they are sent over TCP. So you need to get back a response to request. It also helps with mapping to SIP but even if you were not mapping to another protocol, I suspect you would still need to be able to have an confirmation than and answer was received. 



On Oct 15, 2011, at 2:20 , Iñaki Baz Castillo wrote:

> 2011/10/15 Cullen Jennings <[e-mail]>:
>> Jonathan and I submitted a new draft on setting up media based on the SDP Offer/Answer model. The ASCII flows are a bit hard to read so until I update them, I recommend reading the PDF version at
>> 
>> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf
>> 
>> Clearly the draft is an early stage but we plan to revise it before the deadline for the IETF 82. Love to get input - particularly on if this looks like generally the right direction to go.
> 
> 
> Hi, thanks for this work. IMHO this is clearly the way to go, and the
> proposal that could make everyone happy. Let me just a comment:
> 
> 
> -----------------------------
> 5.3.3.  OK
> The OK message is used by the receiver of an ANSWER message to
> indicate that it has received the ANSWER message. It has no contents
> itself and is merely used to stop the retransmissions of the ANSWER
> -----------------------------
> 
> I wonder how much needed is the OK message taking into account that
> the transport will always be reliable. So, instead of retransmiting
> the ANSWER until an OK arrives, why not retransmit the OFFER until an
> ANSWER arrives and drop the OK message from the spec?
> 
> Probably I miss something here as in the case the offered wants to
> signal ringing (a 180 in SIP) it conveys no media so there would be no
> ANSWER message for long time until the offered human user decides to
> accept or reject the incoming call. If so, please forget this comment
> :)
> 
> 
> 
> 
> 
> 
> 2)
> 
> -- 
> Iñaki Baz Castillo
> <[e-mail]>