Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Randell Jesup <randell-ietf@jesup.org> Mon, 17 October 2011 03:38 UTC

Return-Path: <randell-ietf@jesup.org>
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 B33CF11E8073 for <rtcweb@ietfa.amsl.com>; Sun, 16 Oct 2011 20:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
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 yIX-5nVQ8m-g for <rtcweb@ietfa.amsl.com>; Sun, 16 Oct 2011 20:38:47 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2568F21F85BB for <rtcweb@ietf.org>; Sun, 16 Oct 2011 20:38:46 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RFe2H-0000ym-NO for rtcweb@ietf.org; Sun, 16 Oct 2011 22:38:46 -0500
Message-ID: <4E9BA235.3010808@jesup.org>
Date: Sun, 16 Oct 2011 23:34:13 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <ABB0E87F-DEEF-4386-A718-D48E00F5961A@acmepacket.com> <CALiegfnHuYJnX3rnuDGbZPB4NvK=dCTJ=iLcu+zguP5wo_uPqQ@mail.gmail.com> <92A553E5-107A-4987-A5F5-1F56FB5A7800@acmepacket.com> <CALiegfn6nv1D2HjeMo-jPDh9Acph7JdH1DT1xZXUtHqzqxya3Q@mail.gmail.com> <CA+9kkMB3p1u7hRX_vO1bQbQ2z-V+0rLiJmi+ZqkEA0mqc66keQ@mail.gmail.com> <CALiegf=26_6r_YjBCmO+6_GnrAzi=KcLoPFqUi-y1E8m_gWreQ@mail.gmail.com> <CA+9kkMDsWyKdvXSRMV0OGEeEYbSENFHSOovNJDUGK30N_pGrnQ@mail.gmail.com> <CABRok6nsVH5tYfwFqQpmjF=Kj-wZQDB9XUX8oOee8r3wr51fKA@mail.gmail.com> <CAAJUQMg79h1=V4m9agq9CcEmFknTaaXrgUz9qtq9EL-0_nChiQ@mail.gmail.com> <4E996E80.6070500@alvestrand.no> <CABRok6k=8wa_K7X+MHwaii+6ANfTquLqauMKgm7KP82wf6pKyA@mail.gmail.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E0906A2@ucolhp4d.easf.csd.disa.mil> <CAAJUQMjsRu=eQic002-T-V0rK=1ByRUD8vV2_+C3Q-cHf-ZL4g@mail.gmail.com> <CAAJUQMiV0-w7QBpWk1dc+BprM0T1MiKt-yuH7V9YyZ=vwD=z7Q@mail.gmail.com >
In-Reply-To: <CAAJUQMiV0-w7QBpWk1dc+BprM0T1MiKt-yuH7V9YyZ=vwD=z7Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Mon, 17 Oct 2011 03:38:47 -0000

On 10/16/2011 4:39 AM, Wolfgang wrote:
> On Sat, Oct 15, 2011 at 5:17 PM, Roy, Radhika R USA CIV (US)
> <radhika.r.roy.civ@mail.mil>;  wrote:
>> Folks:
>>
>> A given codec type in known, its parameters should also be known per its specifications. So, it the negotiations between codec-types only.
>>
>> You can see how SDP is used for negotiations between different codec types using SIP. Similar mechanisms can also be used here.
>>
>> Radhika
> So why do we transport some codec parameters outside the media stream
> at all? The called device might need information about the media
> stream before establishing it.

Exactly, and the media stream is unreliable.  This is the purpose of 
sprop-parameter-sets in H.264 SDP.  Also think of gatewaying rtcweb to SDP.

> The server might need access to codec parameters to forward the call
> to the best destination: imagine a user with two RTCWEB clients, one
> only supports only low resolution video, the other one full HD. A high
> resolution video call comes in. How should the server select the
> called client if it doesn't have access to the media stream which
> carries the resolution parameters?

I'm not certain how "the server" would select the client in your 
scenario under any usage; how would the server know before forwarding 
the call which client supported the incoming call's parameters?  Though 
of course you could expose those capabilities to the server explicitly 
when 'registering'.  The problem is that this requires the JS client and 
the server to understand exactly how the codec implementation will 
handle the parameters - you could use a bunch of codec-specific things 
like H.264 does, or generic capabilities.  Generic capabilities won't 
capture all the dimensions of codec negotiation, of course.

> In my model the server would know what type of call was set up as it
> always controls both ends of the call. If some other application
> controls the calling party, you need some standardized protocol like
> SDP.

So the server negotiates the parameters?  I'm not sure what "my model" 
means here (and I reviewed earlier messages from you here).



-- 
Randell Jesup
randell-ietf@jesup.org