IETF Logo Mail Archive

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

Wolfgang <wolfgang.beck01@googlemail.com> Sun, 16 October 2011 08:39 UTC

Return-Path: <wolfgang.beck01@googlemail.com>
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 C540B21F8678 for <rtcweb@ietfa.amsl.com>; Sun, 16 Oct 2011 01:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 rPqFtxNArBd6 for <rtcweb@ietfa.amsl.com>; Sun, 16 Oct 2011 01:39:29 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFE421F8783 for <rtcweb@ietf.org>; Sun, 16 Oct 2011 01:39:29 -0700 (PDT)
Received: by iabn5 with SMTP id n5so5046381iab.31 for <rtcweb@ietf.org>; Sun, 16 Oct 2011 01:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sOXyr9FD1nVvixq4iWI/IapAcGeZfZ6EOvHwIBdHtM0=; b=lm1u4tQe91vMQw4fQvRDGVvz7zf45UhAoKtr+PBJPISIiLHVEmxpqcLH5qiTZG4/vz 4TsxqU7p+0Ku/rxr6ivYYpaf6tFbTOIDtiPFXYW5YAsFafcwXh148lg1BWOEykVNVh/U aSixjsGno+8q24FWqd4T/b36jz09jP6I1vN2c=
MIME-Version: 1.0
Received: by 10.68.73.73 with SMTP id j9mr29401759pbv.67.1318754367557; Sun, 16 Oct 2011 01:39:27 -0700 (PDT)
Received: by 10.68.55.230 with HTTP; Sun, 16 Oct 2011 01:39:27 -0700 (PDT)
In-Reply-To: <CAAJUQMjsRu=eQic002-T-V0rK=1ByRUD8vV2_+C3Q-cHf-ZL4g@mail.gmail.com>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CALiegfkw=aA-4NrAG3U03suUYHAzQHyAWnNEbpRHcjd5xr3_KQ@mail.gmail.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>
Date: Sun, 16 Oct 2011 10:39:27 +0200
Message-ID: <CAAJUQMiV0-w7QBpWk1dc+BprM0T1MiKt-yuH7V9YyZ=vwD=z7Q@mail.gmail.com>
From: Wolfgang <wolfgang.beck01@googlemail.com>
To: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
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: Sun, 16 Oct 2011 08:39:29 -0000

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.

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?

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.


Wolfgang

v2.14.0 | Report a Bug | By Email