- From: Cullen Jennings <fluffy@cisco.com>
- Date: Tue, 12 Jul 2011 07:44:58 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Anant Narayanan <anant@mozilla.com>, public-webrtc@w3.org
On Jul 11, 2011, at 20:22 , Ian Hickson wrote: >>>> >>>> - We added a BLOCKED state in addition to LIVE and ENDED, to allow a >>>> peer to say "I do not want data from this stream right now, but I may >>>> later" - >>>> eg. call hold. >>> >>> How is this distinguished from the stop() scenario at the SDP level? >> >> stop() at SDP is initiated when a stream is ENDED, as mentioned before we'll >> have to come up with a new mechanism (or use an existing RTP mechanism) to >> implement BLOCKED. > > Ah, ok. For interop with existing ICE stacks (e.g. SIP phones) it seems it > would be massively beneficial if we could stick to the currently specified > and implemented set of ICE features, at least for our initial work. :-) There are ways in SDP that are used by current phones to say, I'm not sending a particular RTP stream but allow it to be restarted again in the future. If we can figure out what sort of API we want at the high level, I think I can show how to map this on to existing SDP.
Received on Tuesday, 12 July 2011 14:45:26 UTC