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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 05 February 2014 21:43 UTC

Return-Path: <keith.drage@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 596B71A0129 for <dispatch@ietfa.amsl.com>; Wed, 5 Feb 2014 13:43:18 -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 iALM9NcjtftA for <dispatch@ietfa.amsl.com>; Wed, 5 Feb 2014 13:43:15 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 43AA21A002B for <dispatch@ietf.org>; Wed, 5 Feb 2014 13:43:15 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s15LhAPG022939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 15:43:11 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s15Lh9Nv028834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 22:43:09 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 22:43:08 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Jim Forster <jim.forster@rangenetworks.com>
Thread-Topic: SIP and GSM/UMTS with OpenBTS
Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAABBgYA==
Date: Wed, 05 Feb 2014 21:43:08 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B12ACA2@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com>
In-Reply-To: <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12ACA2FR712WXCHMBA11zeu_"
MIME-Version: 1.0
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 21:43:18 -0000

The requirements cover things like whether you support subscriptions, support roaming between operators, support charging of sessions as opposed to just charging for bandwidth or whatever. That is what you need to identify in order to design a system.

Core network is a 3GPP definition. It is all equipment that is not part of the access network (i.e. not GERAN or UTRAN or E-UTRAN). For what you are talking about, the access network provides an means of communicating using IP, nothing more. So you need a core network. 3GPP may not define it, but as soon as you say something is an activity above IP, a call/session control entity of some sort, that is a core network.

The P-CSCF is an inbound and outbound proxy. It also provides an endpoint for security mechanisms. It also provides the endpoint for policy control for the access network - with restricted bandwidth you may well need that policy control. The definitions are in 3GPP TS 23.228.

http://www.3gpp.org/DynaReport/23228.htm

but you can find a summary (incomplete) in

https://datatracker.ietf.org/doc/rfc4083/

regards

Keith

________________________________
From: Jim Forster [mailto:jim.forster@rangenetworks.com]
Sent: 05 February 2014 18:16
To: DRAGE, Keith (Keith)
Cc: dispatch@ietf.org
Subject: Re: SIP and GSM/UMTS with OpenBTS


A good question for you to answer would be as to which of the requirements of 3GPP TS 22.228 you would support and which you would not support.

http://www.3gpp.org/DynaReport/22228.htm

Wow, that would be quite a job!  Well, I guess it should be looked at.

These requirements led to the development of IMS as it is now, and the IMS architecture is as it is because of those requirements.

Yes, but it starts out with the title:

Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1

Offhand, I don't immediately see the need to have such a thing as an "Internet Protocol (IP) multimedia core network subsystem". OK, certainly a large community (3GPP) does, which is fine and I use that stuff all the time on my phone and so am happy/grateful that it works, but does the rest of the Internet community accept those requirements for other things? What's the boundary for those requirements?  Are they a part of some RTAI or other IETF spec?  I think lots of interesting multimedia activity and specs happen without conformance to those particular requirements.  I'll readily admit to a lot of ignorance and naiveté, but it doesn't seem SIP or WebRTC aspires to support those requirements.  To some degree, OpenBTS is just trying to connect a bunch of nice phones with an OK air interface, to the Internet architecture, which another large set of people seem to like.

OK, I'll duck while the missiles fly overhead :-)
.
 How much are you trying to design something new, versus integrating a P-CSCF and a BTS economically in the same box, which network virtualisation will ultimately do?

Umm, I don't  know what a P-CSCF is, so I'll have to look into it, or please help me/us.

 -- Jim