From: Jim Forster <jim.forster(a)rangenetworks.com> Subject: [dispatch] SIP and GSM/UMTS with OpenBTS Date: February 5, 2014 at 12:09:45 PM GMT+5:30 To: "dispatch(a)ietf.org" <dispatch(a)ietf.org> 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, 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(a)ietf.org https://www.ietf.org/mailman/listinfo/dispatch