Re: [dispatch] SIP and GSM/UMTS with OpenBTS

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Wed, 05 February 2014 20:13 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469C11A0124 for <dispatch@ietfa.amsl.com>; Wed, 5 Feb 2014 12:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjMRNINqgowW for <dispatch@ietfa.amsl.com>; Wed, 5 Feb 2014 12:13:37 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E3E671A00A7 for <dispatch@ietf.org>; Wed, 5 Feb 2014 12:13:36 -0800 (PST)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s15KDYxS014658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 14:13:34 -0600 (CST)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s15KDWkQ007742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 15:13:34 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 15:13:32 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Harvind Samra <harvind@rangenetworks.com>, Jim Forster <jim.forster@rangenetworks.com>
Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS
Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQ
Date: Wed, 05 Feb 2014 20:13:32 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFCD495@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com>
In-Reply-To: <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFCD495US70UWXCHMBA02z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 20:13:40 -0000


I've run into very few mobile folks who think IMS was a good idea.  One of the chief reasons is that SIP, upon which IMS was developed, is a verbose/chatty protocol that occupies way too much bandwidth.
[Raju] I am not sure what these "mobile folks" think about alternatives like XMPP?! :) Not knowing XMPP I think it is complicated!

Some of the alternatives may be webRTC, DIAMETER...

[Raju] WebRTC is NOT a signaling protocol!! Neither Diameter is!! WebRTC only deals with bearer representation (via SDP) and transport while diameter is an "authentication, authorization, and accounting" protocol and not suitable for signaling. That's pretty much leaves us with, whether we like it or not, SIP. Trying to come up with another protocol (and architecture) is like reinventing the SIP/IMS-wheel in another form, which may not please the same folks who don't like IMS/SIP.
We can surely debate on chatty nature of SIP, which I really don't think that chatty. SIP does many things like routing, signaling NAT traversal facilitation, topology hiding, SDP transport etc.  I believe, the SDP is the one which makes it look "chatty", rest of them are headers just like HTTP headers (they are even designed after HTTP/SMTP).
Btw, though it is not signaling, WebRTC is far from simple!! Basically, "it's the devil you know vs. the angel you don't now!"!! :)

-Raju