W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2011

Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Sat, 15 Oct 2011 11:20:41 +0200
Message-ID: <CALiegf=EXfNAfRDGiohz3aSqmZzsDDXbE=DRNX0gZTXz7x4+Yg@mail.gmail.com>
To: Cullen Jennings <fluffy@cisco.com>
Cc: rtcweb@ietf.org, public-webrtc@w3.org, Jonathan Rosenberg <jonathan.rosenberg@skype.net>
2011/10/15 Cullen Jennings <fluffy@cisco.com>:
> 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


Iñaki Baz Castillo
Received on Saturday, 15 October 2011 09:38:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC