Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Wed, 07 September 2011 17:27 UTC

Return-Path: <pravindran@sonusnet.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 0DDFB21F8BD8 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 10:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level:
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 3Wyp9f5-pCKe for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 10:27:49 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 32BDC21F8B70 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 10:27:49 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p87HU41h011811; Wed, 7 Sep 2011 13:30:04 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 13:29:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6D83.AA13C87E"
Date: Wed, 7 Sep 2011 22:59:14 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com>
In-Reply-To: <4E668FB3.9020601@skype.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
Thread-Index: Acxs23hg/0/Jv1DpTUqND6bBZLCykAAkE8Cg
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net>
From: "Ravindran Parthasarathi" <pravindran@sonusnet.com>
To: "Matthew Kaufman" <matthew.kaufman@skype.net>, <igor.faynberg@alcatel-lucent.com>
X-OriginalArrivalTime: 07 Sep 2011 17:29:17.0662 (UTC) FILETIME=[ABC157E0:01CC6D83]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
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: Wed, 07 Sep 2011 17:27:53 -0000

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only. The basic reason for
asking SIP is to make the basic call works between browser to browser
across web servers. Without SIP in browser, it is not going happen.
Innovative application is going to be proprietary whether it is HTTP or
SIP or any other protocol for that matter.

 

My reasoning are as follows:

1)      SIP makes browser more intelligence compare to dump signaling
mechanism like MEGACO and browser acts as MG. 

2)      The importance of basic call interop is that there is no need of
many individual id like skype id, Google id  and yahoo id by everyone in
the world to communicate others. I wish to have single id like e-mail id
to be maintained by browser-to-browser users to communicate with others.


3)      SIP helps to interop for basic call with other existing realtime
application in Enterprise & Telecom provider.

4)      There is no need to build two different signaling logic in VoIP
servers for each service. Your own example of Bridge line appearance
will need two implementation by the single vendor because desktop
application or hardphone implementation based on SIP and browser based
implementation is depend on HTTP metadata. It is possible to avoided by
having one signaling protocol.

 

In RTCWEB does not standardize the signaling protocol interface between
browsers, the interop across webservers is next to impossible and it
will be restricted to single webserver (company) only. Please let  me
know in case I'm missing something here.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] 
Sent: Wednesday, September 07, 2011 2:55 AM
To: igor.faynberg@alcatel-lucent.com
Cc: Ravindran Parthasarathi; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote
recording - RTC-Web client acting as SIPREC session recording client]

 

On 9/6/11 6:13 AM, Igor Faynberg wrote: 

I find this reasoning hard to understand.  First, the SIP standard has
been around for a decade. What new standardization is needed?


The issue is whenever you wish to innovate and add functionality.

See the long, long list of RFCs that extend SIP. For some examples:
RFC3515 - Refer method
RFC3842 - Message waiting
RFC3891 - Replaces header
RFC3911 - Join header
RFC3960 - Early media
RFC4411 - Reason header for preemption

Never mind all the things that aren't even finished...

draft-ietf-bliss-shared-appearances
draft-ietf-bliss-call-park-extension

true bridged line appearances

etc

etc

If all you want is a basic point-to-point phone, there's a short list of
RFCs you implement and you're done. But that isn't a platform for
innovation... it is just a phone.

Matthew Kaufman