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

On 02/05/2014 11:47 AM, Tim Panton new wrote:
>
> On 5 Feb 2014, at 06:39, Jim Forster <jim.forster@rangenetworks.com 
> <mailto:jim.forster@rangenetworks.com>> 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.
Here is room for some enhancements, adding to preconfigured handover / 
roaming.

A simple mechanism to propagate and apply a ruleset, such that each BTS 
responsible for the registration
can indicate whether a) A foreign MS is allowed to handover / roam to 
this BTS, and b) A local MS is allowed to request its information via a 
foreign
BTS. This will allow policy based mobility, i.e. bilateral agreements 
between BTS's. My 2 c worth.

Gullik

>
>> * 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 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.
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch