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

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 05 February 2014 15:17 UTC

Return-Path: <mary.ietf.barnes@gmail.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 A73391A01FD for <dispatch@ietfa.amsl.com>; Wed, 5 Feb 2014 07:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XD--t90mD2iu for <dispatch@ietfa.amsl.com>; Wed, 5 Feb 2014 07:17:50 -0800 (PST)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 083771A0204 for <dispatch@ietf.org>; Wed, 5 Feb 2014 07:17:49 -0800 (PST)
Received: by mail-yh0-f49.google.com with SMTP id t59so507793yho.8 for <dispatch@ietf.org>; Wed, 05 Feb 2014 07:17:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kNftQyB/qEKCDLvjpQRWfz5WU1Q5muab2t2/Qk1x9Xg=; b=VQvlaV3t2hC0WX9dblAHxlei2UTgYu/Y+VJx5VoQ5cze/fRn0aPIY43eTGzXUID4xs M4LKuhdTU+qEC4rQJQA68fDGY1cPORggy1wHLoezSDy3g45+jJpXhNjcEFmFFbcBpL6G J/EkqCxOJZ4hARzYgHKv7sVnK93Glo+07e2LgLPDOMzNo/jyZJnkjevyeTRtR3AMPn62 1cLOBTy82WsDiIcjrHQS8LsOILsS7jnA3F2OrZ/eIrZ8PGM3zTjTB4c0HuKzRwdnoyRN 4CgzmoFn4ngpxqUtD94CVGmTxj5bKUmPAeyyJ1LoTB+Ak7LEYN/DsNEJ3hsdu8qvL3ks wHBw==
MIME-Version: 1.0
X-Received: by 10.236.193.200 with SMTP id k48mr79163yhn.159.1391613468944; Wed, 05 Feb 2014 07:17:48 -0800 (PST)
Received: by 10.170.46.143 with HTTP; Wed, 5 Feb 2014 07:17:48 -0800 (PST)
In-Reply-To: <52F25265.5070108@alum.mit.edu>
References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <52F25265.5070108@alum.mit.edu>
Date: Wed, 05 Feb 2014 09:17:48 -0600
Message-ID: <CAHBDyN4KaZJZyysA0OL7OvDP-zQY-GJxrsQ+M_cD9gGKKfD0ZQ@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="bcaec50dc1c07b2dd304f1aa42b8"
Cc: DISPATCH <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 15:17:58 -0000

He is just a couple days  late for the DISPATCH process:
http://tools.ietf.org/wg/dispatch/trac/wiki
The chairs were aware of this request within the required timeframe.  Jim
had originally contact ADs about a Bof and they referred JIm to the
DISPATCH chairs.

There is no requirement whatsoever that work goes through an official IETF
Bof prior to being chartered.  Depending upon how this mailing list
discussion goes, the DISPATCH chairs will decide whether this topic gets
agenda time in DISPATCH or whether a less formal discussion would be
optimal (although, scheduling time for that in a venue that will be
expeditious will be difficult given the current RAI schedule).

Mary.
DISPATCH WG co-chair


On Wed, Feb 5, 2014 at 9:01 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Jim,
>
> I'd be interested in hearing more about this.
> But you are tardy in bringing this up for London.
> The deadline for scheduling BOFs has passed. (And you would have need to
> do quite a bit more to stimulate interest to get one scheduled.)
>
> In principle you could ask for agenda time in dispatch. But that is
> typically only granted for subjects that have had discussion and interest
> on the dispatch mailing list.
>
> So you are doing the right thing to get started, by beginning discussion
> on the dispatch list. But it is unlikely that you can do anything about it
> *formally* in live sessions in London. You might want to set yourself a
> goal to generate sufficient interest to do something at the following ietf
> in Toronto.
>
> For the London meeting you could make an effort to set up something
> informal, such as a "Bar BOF". But the main thing, even for that, is to
> develop a set of interested followers via email.
>
>         Best wishes,
>         Paul
>
>
> On 2/5/14 1:39 AM, Jim Forster wrote:
>
>> Dear DISPATCH group,
>>
>> OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new
>> and interesting ways.  I think there is some value to the community in
>> discussing these in the DISPATCH mailing list and having an related
>> meeting at the London IETF.  There is both some short-term, relatively
>> straightforward work to be done to agree on the usage of SIP in these
>> existing implementations. There may also be some very interesting work
>> to be done on more advanced approaches.
>>
>> First, some background: OpenBTS is an open source project started by the
>> founders of Range Networks to make a 'GSM system in a box', by
>> implementing a system which supports the air interface for GSM phones
>> (Um) using a Software Defined Radio (SDR) for the RF.  While the GSM &
>> 3GPP defined air interface to the phones is supported, OpenBTS diverges
>> from these standards by immediately gatewaying the call to SIP.  Each
>> GSM or UMTS phone can then appear on the Internet as a SIP endpoint.  A
>> local SIP switching decision is made to route the call; Asterix,
>> Freeswitch, Yate have been.  The call is then sent to another local
>> connected phone or to some other SIP service point on the Internet.
>>
>> With this in place, because the air interface to the phones is supported
>> with no changes, standard GSM/UMTS phones can make calls to other phones
>> on the same OpenBTS system or to any SIP endpoint on the Internet, and
>> thence to the PSTN via any of the many SIP-PSTN gateways in operation.
>>
>> A fair question would be "Why do all this?  What's wrong with GSM & 3GPP
>> systems?".  One reason is that the OpenBTS approach allows very small,
>> stand alone systems, which efficiently connect GSM and UMTS phones to
>> the Internet based SIP systems with a minimum of other systems.
>>   Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP
>> 'Core' which is usually beyond the means of smaller users. OpenBTS
>> aspires to be the simplest way for a GSM/UMTS phone to make phone calls
>> to the SIP & PSTN world.
>>
>> At least several hundred, and likely several thousand of these systems
>> are deployed already.  Many are in labs, but others are production usage
>> on all continents.  Universities find these systems very attractive for
>> teaching and researching: all the code from RF to Signaling is visible
>> and may be changed as desired.
>>
>> Furthermore, additional SDRs are popping up all the time.  There are 3-4
>> separate SDR based systems that run OpenBTS and more are coming.  Right
>> now they range from $2000 up, but it's easy to see them dropping to $500
>> or so this year; even Kickstarter campaigns are funding some of them.
>>   There's no natural floor below that; adding GSM/UMTS to a home router
>> and making it a micro-cell running SIP to the Internet could conceivably
>> be a $10 HW delta and some more SW.  Secondly, there are several
>> countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so
>> some efforts are underway to do exactly that.
>>
>> When facing the Internet, OpenBTS is simply a SIP client.  However, to
>> assure interoperability, there may be value in standardized behavior,
>> including these issues:
>>
>> * Which elements of SIP are needed for this operation?
>> * Should these be documented in a profile of SIP usage to be OpenBTS
>> Ready?
>> * Should ICE be recommended or possibly be required for operation behind
>> NATs?
>> * What about BTS-BTS neighbor discovery
>> * Use of SIP Re-invite for hand-over when a mobile phone moves from one
>> BTS to a neighbor
>> * For somewhat different use cases: one could separate signaling from
>> media transport and thus might support WebRTC or other such systems.
>>   E.164 addresses are used in phones, but temporary numbers can be
>> assigned as needed (as done in Roaming) and not surfaced to the WebRTC
>> level.
>> * What Changes required for IPv6?
>> * Required and recommended security provisions
>> * Is IETF an appropriate forum for this, or should it be in 3GPP, or
>> Sipforum.org <http://Sipforum.org>,  or a separate industry group formed?
>>
>>
>> I look forward to discussion on the mailing list, and hopefully meeting
>> and discussing in London.
>>
>> Yours,
>>
>> Jim Forster
>> Range Networks
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>