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

[Paul Kyzivat <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>