On Wed, Jul 3, 2013 at 3:11 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
> I'm hearing a mixed message.
>
> 1. This is the first time I hear of someone referring to SDP as an
> API. It is no more an API than JSON. It is simply a collection of key-value
> pairs.
> 2. I was personally told by the WebRTC specification editors that
> users are not meant to interact with SDP directly.
>
>
> I think everyone would benefit from the specification editors to stand
> up and give some official responses.
>
This logic, once again reminds me of the poem Haddocks' Eyes:
But I was thinking of a plan
To dye one's whiskers green,
And always use so large a fan
That they could not be seen.
Why introduce something that is not supposed to be seen or touched by
anybody. If we have a blob that we are not suppose to interact with, we
will need an API to examine it and get all the relevant information. If we
have such an API why do we need the underlying blob at all? Also, if you
want this to be the standard you will need to define everything that can be
present in this blob and what it means. You might define an API with the
same amount of effort. Building thing currently feels like driving a barge
using chopsticks (constraints) with your eyes closed.
Returning to my original email, why does real time communication channel be
setup by exchange of one big blob? ICE candidates, encryption, mapping
media streams to RTP streams and encoding are independent. Why should they
be negotiated at the same time? Finally, why are we talking in terms of
offers and answers at all. These are artificial constructs which should not
be present in the API.
_____________
Roman Shpount