Re: [rtcweb] RTCweb signalling overview

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 09 September 2011 15:50 UTC

Return-Path: <mary.ietf.barnes@gmail.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 7874321F8A67 for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 08:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.461
X-Spam-Level:
X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 blf9DDA1EMlx for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 08:50:28 -0700 (PDT)
Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 256A521F85D1 for <rtcweb@ietf.org>; Fri, 9 Sep 2011 08:50:28 -0700 (PDT)
Received: by vws10 with SMTP id 10so1026393vws.16 for <rtcweb@ietf.org>; Fri, 09 Sep 2011 08:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ywB0V/3KOkzANjgVXd2ww9MK1RjntW54ZFh693dU/FQ=; b=dzc3whA7flWhiwcETxUl2jdcG2TwZVoeb3hI2OdaGDwwqg1CD/FpxU9wZFjjEM8jko XGleRnvLHWUUaZTlWsK7n8HfXOhLrn9ZN1pX9/RXUuskYsL25KmZjEUsT4WSWr2MFmHH WWtDuQpaNpKPXfPBQivUfLkZsJVV7Qct6+PKg=
MIME-Version: 1.0
Received: by 10.52.70.100 with SMTP id l4mr771480vdu.23.1315583543128; Fri, 09 Sep 2011 08:52:23 -0700 (PDT)
Received: by 10.52.35.2 with HTTP; Fri, 9 Sep 2011 08:52:23 -0700 (PDT)
In-Reply-To: <1D062974A4845E4D8A343C653804920206557F48@XMB-BGL-414.cisco.com>
References: <E2827B1C-5706-41D0-8D96-D342C25901D1@edvina.net> <4E69BF72.5060908@alvestrand.no> <EDC0A1AE77C57744B664A310A0B23AE220BA3C91@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <1D062974A4845E4D8A343C653804920206557F48@XMB-BGL-414.cisco.com>
Date: Fri, 9 Sep 2011 10:52:23 -0500
Message-ID: <CAHBDyN5iPb0OsHaiLVKQsxRkjz06DPyPm+yvknVfaBZwAkhKZg@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: multipart/alternative; boundary=20cf307ac75fc2b0d504ac8429a8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCweb signalling overview
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: Fri, 09 Sep 2011 15:50:29 -0000

Yes, federated SIP certainly has the problems that VIPR is intended to
solve.  And, of course, without VIPR or without SPs supporting Federations
and/or ENUM, the only choice is to interwork via the PSTN.  However, given
that there are multiple solutions for SIP based federation, it makes sense
to not reinvent the wheel and trying to suggest that you only need a subset
of SIP for this interface is a slipperly slope as has already been
suggested. And, of course, using SIP as is on this interface facilitates
interworking in cases where the Web Server is interfacing to a "legacy" SIP
Server.  As an aside, I think it's silly to refer to the SIP protocol
developed by the IETF as "legacy".   I don't think the intent of RTCWEB is
to marginalize SIP.   As Keith suggests, it may be that some additional
information needs to be passed over that interface to support RTCWEB, but I
would hope that would not require core SIP changes.

Mary.

On Fri, Sep 9, 2011 at 8:25 AM, Muthu Arul Mozhi Perumal (mperumal) <
mperumal@cisco.com> wrote:

>  |Perhaps the easiest way out is to identify that full ****
>
> |blow SIP is a solution for this specific interface, ****
>
> |and RTCWEB identifies to SIPCORE as to whether there ****
>
> |are any additional requirements that SIP cannot meet.****
>
> ** **
>
> Doesn't this federated SIP suffer from the same problems VIPR is trying to
> solve? Of course, the alternative is to choose SIP trunk providers and go
> through SBCs and PSTN -:)****
>
> ** **
>
> Muthu****
>
> ** **
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On
> Behalf Of *DRAGE, Keith (Keith)
> *Sent:* Friday, September 09, 2011 6:39 PM
> *To:* Harald Alvestrand; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] RTCweb signalling overview****
>
>  ** **
>
> With respect to question 3 in this set.****
>
> ** **
>
> As I said on the call, the requirements for what needs to be standardised
> between the two web servers depends on whether web server A needs to know
> anything about user B, and whether web server B needs to know anything about
> user A. I believe this goes beyond SDP, because it may need to be
> information beyond the media contents, e.g. it may need to include
> information about each user’s capabilities and preferences.****
>
> ** **
>
> I actually have two slightly inconsistent views about this interface.****
>
> ** **
>
> Yes it does need to be standardised. I don’t like the idea of fragmentation
> being forced on the market because an appropriate standardised solution has
> not been identified. ****
>
> ** **
>
> No RTCWEB should not standardise it because it is out of scope of RTCWEB.*
> ***
>
> ** **
>
> Surely this is also the interface by which support of interworking with
> legacy systems has to be attained?****
>
> ** **
>
> Perhaps the easiest way out is to identify that full blow SIP is a solution
> for this specific interface, and RTCWEB identifies to SIPCORE as to whether
> there are any additional requirements that SIP cannot meet.****
>
> ** **
>
> Regards****
>
> ** **
>
> Keith****
>
> ** **
>
> ** **
>
> ** **
>   ------------------------------
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On
> Behalf Of *Harald Alvestrand
> *Sent:* 09 September 2011 08:26
> *To:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] RTCweb signalling overview****
>
> ** **
>
> On 09/08/11 20:48, Olle E. Johansson wrote: ****
>
> For those of you that did not participate in today's meeting, there was an
> excellent overview presented by Martin Kaufman. ****
>
> ** **
>
> It gives you an overview over the issues with signalling - to sip or not to
> sip - and other issues. Do read it.****
>
> ** **
>
> Use the file rtcweb-3.pptx<http://www.ietf.org/proceedings/82/slides/rtcweb-3.pptx>
>  in http://www.ietf.org/proceedings/82/slides/****
>
>
> Seconded.
> I liked the presentation even though I don't agree with the conclusions (I
> prefer Cullen's set).
> **
> ******
>
> ** **
>
> /O****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> rtcweb mailing list****
>
> rtcweb@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>