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
- [rtcweb] Signalling, SDP, and the way we think ab… BeckW
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Hadriel Kaplan
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Hadriel Kaplan
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Ted Hardie
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Hadriel Kaplan
- Re: [rtcweb] Signalling, SDP, and the way we thin… Ted Hardie
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Neil Stratford
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Harald Alvestrand
- Re: [rtcweb] Signalling, SDP, and the way we thin… Neil Stratford
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Harald Alvestrand
- Re: [rtcweb] Signalling, SDP, and the way we thin… Neil Stratford
- Re: [rtcweb] Signalling, SDP, and the way we thin… Roy, Radhika R USA CIV (US)
- Re: [rtcweb] Signalling, SDP, and the way we thin… Stephan Wenger
- [rtcweb] VP8 and parameters (Re: Signalling, SDP,… Harald Alvestrand
- Re: [rtcweb] Signalling, SDP, and the way we thin… Dzonatas Sol
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Dzonatas Sol
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang Beck
- Re: [rtcweb] Signalling, SDP, and the way we thin… Iñaki Baz Castillo
- Re: [rtcweb] Signalling, SDP, and the way we thin… Ted Hardie
- Re: [rtcweb] Signalling, SDP, and the way we thin… Dzonatas Sol
- Re: [rtcweb] Signalling, SDP, and the way we thin… Randell Jesup
- Re: [rtcweb] Signalling, SDP, and the way we thin… Wolfgang Beck
- Re: [rtcweb] Signalling, SDP, and the way we thin… Cullen Jennings