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

[Harald Alvestrand <[e-mail]>]

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.

                    Harald