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

[Tim Panton new <[e-mail]>]

On 5 Feb 2014, at 06:39, Jim Forster <[e-mail]> wrote:
> 
> When facing the Internet, OpenBTS is simply a SIP client.  However, to assure interoperability, there may be value in standardized behavior, including these issues:

It may be a SIP client, but in some ways it is a non-traditional one, a single BTS may well present as multiple phones (possibly thousands) like a giant ATA bank of old.

> 
> * Which elements of SIP are needed for this operation?

We need to go through the uM (GSM air interface) and document how that maps to SIP, this will give us a 
list of SIP actions that need to be supported to make a working UM cell

> * Should these be documented in a profile of SIP usage to be OpenBTS Ready?

Yes, but we need a better name - UMSIP  perhaps? 

> * Should ICE be recommended or possibly be required for operation behind NATs?

My experience of trying to install these things is that NAT is a persistent problem, getting an internet connection into
a village in the middle of nowhere is hard enough, expecting it to have an unfiltered public IP address is too much to ask.
Fall back methods of running a VPN or using rfc5456 are both unsatisfactory. ICE will help with the RTP streams, 
but we need to get the SIP flowing too - perhaps SIP over TCP or even websockets is a better fit?

> * What about BTS-BTS neighbor discovery

In order to handover a moving call to the next cell, a BTS need to know where the next cells are, at the moment
openBTS uses a private protocol/config. It would be great if we could use a suitable pre-existing SIP mechanism and document that
usage.

> * Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS to a neighbor

Or some other mechanism.

> * 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 think the IETF has solved most of these problems in other cases, so it makes sense to try and leverage that knowledge in this space, 
and try to produce a document that lets multiple UMSIP vendors interoperate and SIP trunk/PBX  vendors know what they need to do to support these new devices.

Tim.