HI,
It would be better if PeerConnection::createOffer/createAnswer() returns a
capability object, which should be easily extendable for future parameters.
This object should resumble the SDP, so that the application developer can
easily create an SDP, based on the parameter in the capability object.
Probably this solves the drawbacks of the existing SDP.
the following are the identified problems/solutions for capability
negotiation.
1. SIP capability -- JS application prepares SDP in string format from
the parameters in the capability object.
2. XMPP-JINGLE -- JS application prepares SDP in xml format from the
parameters in the capability object.
3. Proprietory/Other -- JS application prepares its own
proprietory/Other format of capability from the parameters in
the capability object.
4. Future expected/invented properties/parameters can be easily extended to
the capability object.
5. The application can prepare its own supported version of
SDP/capabilities (example .. some legacy devices may not support the
proposed features)
6. The object resumbling SDP will make the applications using legacy
signaling protocols (expected major clients for webrtc) to easily prepare
the SDP.
7. Provides abstraction to the lower level API.
This solution incurs extra burden of preparing SDP from the capability
object.
Thanks,
Kiran.
On Mon, Jul 8, 2013 at 6:57 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> On 08/07/2013 8:43 AM, Adam Bergkvist wrote:
>
>>
>> I agree, and (sorry to say) I think that the specification editors
>>> have to bare the brunt of the blame.
>>>
>>> We put out some good discussion points and haven't received a
>>> single reply from them over the past 2 weeks. Why? They could have used
>>> the momentum to drive a constructive discussion.
>>>
>>> Debating is useless unless it results in actionable items. We're
>>> going to be hard-pressed to produce anything actionable without the spec
>>> leads engaging the community.
>>>
>>> Gili
>>>
>>
>> I wish that I, as a spec editor, could edit the spec after my own
>> preferences; the spec would have looked a lot different and we would have
>> been done by now. ;) (stolen quote) But the editors team's task is to edit
>> the document after group consensus; which isn't always easy when we can't
>> reach consensus on stuff.
>>
>> Personally I think the fact that we're not progressing and the way the
>> API has been received, by the people who are intended to use it, clearly
>> indicates that we're not doing it right. Less dependence on decisions from
>> other groups and requirements coming from the top, instead of from what
>> happens between UAs on the network, would also make our lives easier IMO.
>>
>> I'm looking forward to see the API proposal and I'll be happy to comment
>> on it.
>>
>> /Adam
>>
>> Hi Adam,
>
> Thanks for breaking the silence :)
>
> I'm not expecting editors to edit the spec after their own
> preferences, but I do expect you to expose a design document which explains
> the decisions made to date. At the very least, it would help us avoid
> repeating the same arguments (many of them based on assumptions of why
> certain design elements have to remain in place). The design document
> should document all use-cases being addressed by WebRTC and how the API
> addresses each one.
>
> It's very important to keep on engaging the community, in order to
> collect and document this information. I hope this clarifies what I meant.
>
> Take care,
> Gili
>
>