- From: Roman Shpount <roman@telurix.com>
- Date: Fri, 28 Jun 2013 19:24:25 -0400
- To: Ted Hardie <ted.ietf@gmail.com>
- Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>, Gili <cowwoc@bbs.darktech.org>, public-webrtc@w3.org
- Message-ID: <CAD5OKxsV1w8iLSnNrGhWGxcco37xbAiiRp-jPSUnoc=O95j-8Q@mail.gmail.com>
On Fri, Jun 28, 2013 at 7:10 PM, Ted Hardie <ted.ietf@gmail.com> wrote: > On Fri, Jun 28, 2013 at 3:02 PM, Roman Shpount <roman@telurix.com> wrote: > >> The functionality I need to implement (as a developer or as teleco or as >> implementer) is to capture audio or video and send it to the remote party. >> Or alternatively I want to receive audio or video from remote party and >> play it out locally. >> > > For what it's worth, the high level abstraction you put forward is pretty > much what I believe the rtcweb group sees as the problem space: plumb a > local media source or application data stream so that it is played out/used > locally or sent across a network to a peer, who must then be able to use it > in a way understood by the application. > > This is kind of the point. This group mandate is to implement these features, not to design SDP bundle. > But, as the case is so often, there are many details, and some have them > have devilled us a long while. > We are actually not planning to remove any of the features. The intent is to unbundle the functionality provided by SDP and offer/answer into JavaScript API calls. This is already done internally in WebRTC implementation, so we want to expose it the API. Hopefully without introducing additional security issues. The group is already moving this way by adding side channels to offer/answer negotiation with trickle ICE and no plan proposals. We are already (or at least seriously considering) setting communication addresses and media lines via JavaScript API calls. I think we just need one more push and SDP and offer/answer will become unnecessary and redundant. _____________ Roman Shpount
Received on Friday, 28 June 2013 23:24:54 UTC