IETF Logo Mail Archive

Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

"Olle E. Johansson" <oej@edvina.net> Tue, 20 September 2011 09:01 UTC

Return-Path: <oej@edvina.net>
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 2574B21F8AB0 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 02:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.242
X-Spam-Level:
X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 FnJwmJDffW7j for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 02:01:46 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA521F8876 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 02:01:46 -0700 (PDT)
Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 83B5B754BCE4; Tue, 20 Sep 2011 09:04:10 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="us-ascii"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <D56D6784-1700-4777-98F4-CAF9BEAF7751@acmepacket.com>
Date: Tue, 20 Sep 2011 11:04:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <142BBF6F-F3D5-4D04-8F65-2B1C4CF1A2A2@edvina.net>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><CALiegfkTdCAeEdZbXP1Y9L6i4Anjrgf1CG6ZNj35WGoHL3p_Ew@mail.gmail.com><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><CEA0AC9E-6387-4066-95DC-0D70302E80A7@ag-projects.com><4E77C3EC.9060801@jesup.org> <CAD5OKxtciYxaVpb7b3G9yMg1A97b9dkjkOpppZcSRzS5SAO3+A@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <C55E752E-18FD-402C-A7DE-1627813B3F6D@acmepacket.com> <4E78351C.20103@jesup.org> <E4C646E9-44E5-4EBE-9AA1-D97500FAEE66@acmepacket.com> <4E7844B7.80000 05@jesup.org> <BB52C621-1D9E-41DD-B36B-28404740A1FE@acmepacket.com> <DA32EB0C-EDBF-45DE-A654-6CDF772DC4DC@edvina.net> <D56D6784-1700-4777-98F4-CAF9BEAF7751@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: Randell Jesup <randell-ietf@jesup.org>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
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: Tue, 20 Sep 2011 09:01:47 -0000

20 sep 2011 kl. 10:56 skrev Hadriel Kaplan:

> 
> On Sep 20, 2011, at 4:48 AM, Olle E. Johansson wrote:
> 
>>> If it could, we'd probably have the siprec/remote-recording requirement accommodated.  :)
>> Well, take a look at the source code for FreeSwitch or Asterisk and you'll see that "setting up a bridge" is not a piece of cake...
>> You are making the assumption that you have no formatting issues and don't need to change framerate for video, orientation or anything else or audio transcoding.
> 
> Nope, I'm not making any such assumption.  I was just pointing out that if the browser did full mixing, then we'd have the remote recording use-case thing done too. 
> 
> 
>>>> SIP has been very focused on device<->server interaction, not device<->device.  However:
>>>> note that we have an app that knows why it has these calls in place; we're not defining an
>>>> abstract, portable protocol use here.
>>> 
>>> Aha!  So it's not "SIP" that you meant... you meant "something that looks like SIP but isn't SIP per the RFCs".  ;)
>>> 
>> According to RFC 3261 SIP is a peer 2 peer protocol and not a device->server protocol. Just making a point.
> 
> I'm not sure if you meant that in response to my remark or Randell's?  What I meant by saying "it's not really SIP" wasn't because I think SIP is not device<->device (on the contrary, it is)... but rather that if rtcweb uses SIP but then doesn't actually follow the rules of SIP, then it's *not* SIP.
> 
Sorry, both comments was meant for Randell. But thank you for your response :-)

My opinion is that a limited version of SIP for rtcweb would not only be impossible to develop and keep in a limited scope, it would hurt the RTCweb process. And it's interesting to observe how many SIP oldtimers in this list that maintain that opinion...

It might be something worthwile to define in the process of trying to move SIP towards the Internet Standard goal, but that's a separate issue.

/O

v2.23.0 | Report a Bug | By Email