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

Harald Alvestrand <harald@alvestrand.no> Wed, 05 October 2011 12:32 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A88E21F8B18 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.361
X-Spam-Level:
X-Spam-Status: No, score=-108.361 tagged_above=-999 required=5 tests=[AWL=1.638, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HRuiRWClQd8 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:32:53 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D542621F8AFD for <rtcweb@ietf.org>; Wed, 5 Oct 2011 05:32:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BA7239E0A7 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:35:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MirKP2WE9O4 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:35:53 +0200 (CEST)
Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9D26939E048 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:35:53 +0200 (CEST)
Message-ID: <4E8C4F28.4070506@alvestrand.no>
Date: Wed, 05 Oct 2011 14:35:52 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMBi9BzDu=WOq3RG-o5nbfnUTftDg3LRBU3DFh=Kc4W5ZQ@mail.gmail.com> <CALiegfmYgQ+yb=pDp1J2_PVa1SkxTOuaUCM02Vt6-iGabwif1g@mail.gmail.com> <CA+9kkMCUTiPO3eASjn0mbRA9YCF6TMmGGOjQ4NkVkvzVMN39Gg@mail.gmail.com> <CALiegfnx=qoS_pqyC45WVEYEFqj-3eP9g_kyhAUaOO6He_UEfw@mail.gmail.com> <91623260-6A12-4737-8BA9-4D6B60FCD389@phonefromhere.com> <CALiegfk_6pviBMBmYUvj69JA73Uy0rnXaMvThPuGT2R5NOWycQ@mail.gmail.com> <0EF30DF7-91D2-48A5-90BD-B7E7CA3C61E4@phonefromhere.com> <CALiegf=GpVUQb7cPMQH+4DpO_fvYPP7LjyyZ8uO5r13hDQORyQ@mail.gmail.com> <D17EDB43-3C1D-4C35-94A9-1C9FEF6EE36C@phonefromhere.com>
In-Reply-To: <D17EDB43-3C1D-4C35-94A9-1C9FEF6EE36C@phonefromhere.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2011 12:32:53 -0000

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<tim@phonefromhere.com>om>:
>>>> 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