On 07/20/11 12:39, GÃ¶ran Eriksson AP wrote:
>
> On 2011-07-19 13.20, "Harald Alvestrand"<harald@alvestrand.no> wrote:
>
>> On 07/18/11 23:07, Ian Hickson wrote:
>>> On Mon, 18 Jul 2011, Prakash wrote:
>>>> Excellent. Thanks Ian. I was most concerned about interop with non
>>>> browser/existing systems. If the message is not opaque, then anyone
>>>> should be able to translate it if needed.
>>> Indeed. Compatibility with SIP in particular was high on my mind when
>>> designing this API; the intent is that it should be almost trivial to
>>> do a
>>> SIP gateway for this stuff. (I mean, as trivial as this stuff can get,
>>> anyway...)
>>>
>> FWIW, this is one area where Ian and I still don't agree; I think SDP is
>> a representation format we need to avoid, and that we're better off with
>> a JSON-based format where the relevant information can be easily
>> transformed into SDP when needed.
> Just to make sure I understand- it is only the format You dislike, not the
> semantics and/or the procedures as such of SDP?
I also think that the semantics are ill-defined, with all too much stuff
that is context-specific done as if it was general, and general stuff
done in different ways for different media types, and the procedures are
vague (basically, what an SDP data blob means is defined by context - so
we have to talk about the procedures SIP (or others) uses for SDP, not
about "SDP procedures" in general).
It's reasonably clear to me that if dropping the SDP format is to be
useful, it has to come with a commitment to not import the parts of SDP
that don't make sense in this context (instead of just allowing it in
and then ignoring it in the implementation). That's Cullen's option 2 -
and the fact that people are extending SDP to add stuff needed by new
codecs is, in my opinion, a clear indication that we got the layering wrong.
Harald