Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Tim Panton <[e-mail]>]

On 5 Oct 2011, at 13:35, Harald Alvestrand wrote:

> On 10/05/2011 01:05 PM, Tim Panton wrote:
>> On 5 Oct 2011, at 11:40, Iñaki Baz Castillo wrote:
>> 
>>> 2011/10/5 Tim Panton<[e-mail]>:
>>>>> Your points are perfectly valid and should indeed be covered. But I
>>>>> didn't want to be so explicit in my immature API suggestion. It was
>>>>> just an overview.
>>> 
>>>> I guess what I was getting at was the fact that the SDP seemed
>>>> central to the API - I'd like something more generic and javascript
>>>> friendly as the central concept.
>>> 
>>> Hi Tim. At the end you web application will receive (via the custom
>>> signaling) something "like" and SDP containing the media information
>>> offered/answered by the peer (when receiving or initiating a media
>>> session).
>> 
>> 
>>> This is: your web browser needs to know the remote IP:port, the media
>>> streams, supported codecs by the peer... At the end that looks like a
>>> SDP. And such "SDP" should be retrieved by your web application via
>>> some signaling protocol (on top of HTTP or WebSocket), and you will
>>> receive it as a JSON object, or XML, or whatever format.
>> 
>> Agreed. We are now getting down to the format, I'd like to see the
>> codec capabilities separated from the network ports , as to my mind they
>> are orthogonal. SDP gets into all sorts of complexity with IPv6 (e.g. happy eyeballs)
>> partly because it intermixes the 2 things.
>> 
> Unfortunately the two things are tied together in nontrivial ways by our choice of RTP.
> 
> The media engine has to generate RTP packets, which have to be marked with a specific payload type (negotiated between the endpoints to represent the codec), and have to have an SSRC and IP destination address put onto them that will cause the remote end to identify the RTP session (from IP address) and media stream (from SSRC) correctly; since PT values are only valid within a single RTP session, it follows that one cannot deduce the codec from the incoming packet without being party to the negotiation of IP addresses.
> 
> I'm certain this can be represented in a cleaner way than SDP currently does it. But "orthogonal", if taken at face value, seems to hope for a more well structured world than is currently achievable.

- ah, now you have dashed my hopeful optimism and made me sad ;-)

Seriously - I think that they remain orthogonal during the _selection_ process. It isn't until we actually _commit_ to a set of codecs/ports etc
that they become intertwined. I guess I'm hoping that we can hide that from the Javascript coder without limiting the flexibility of
the API we present them by delaying the inevitable complexity as long as possible.

Tim