OpenSIPS Was: transceiver won't start; fpga build error

historical

Stephane,

Sorry for slow response.

On Wed, Mar 27, 2013 at 9:30 PM, <stephane at shimaore.net> wrote:
> > Do you think we could use OpenSIPS not only as a registrar, but also
> > as an authentication server?
>
> As I understand how OpenBTS works, I think the registrar does the
> authentication of the phone as well. I haven't tried though (I don't
> have blank SIM cards or cards with known keys).
>
> > And what do you think about routing calls with it? I was told that the
> > best way to get it to scale is to use static routing, i.e. without an
> > access to an external DB. But now the problem is that subscribers move
> > from a BTS to a BTS and it can't be completely static.
> > One solution is
> > to actually have Location Areas as in GSM and use broadcasted SIP
> > INVITEs in them. Or alternatively we could do some "virtual LA" on SIP
> > level by creating a layered set of OpenSIPS instances.
>
> You'd scale this in similar ways you would scale a storage infrastructure,
> with "many writes - one read" by duplicating ("broadcasting") the
> REGISTER messages to multiple registrar instances; then during routing
> you can query (=forward INVITEs to obtain 302 routing responses) to any
> registrar.
>
> REGISTER messages and INVITE messages don't have to be processed by the
> same proxies either; you create a line of front-end proxies that can
> talk to OpenBTS, another one that can talk to SS7 gateways, etc.
> This also allows you to modify the setup behind those front-end proxies
> without having to modify OpenBTS / gateways / etc.
>
> For very large systems you would spread out the back-end load over
> multiple registrar clusters based on an arbitrary random key (e.g. the
> last 2 digits of the IMSI, or whichever identifier is used to
> authenticate/route) which you then use to locate the proper
> registrars (easiest way is using DNS: for example you'd say that
> information about IMSI xxx..x56 can be found on cluster
> "registrar-56.phone.example.net", and the front-end servers will do the
> proper processing for OpenBTS / SS7 gateways / whatever).

Thank you for the information!
Now we just have to implement that :)

> > SMS is another issue, because it requires a "store and forward"
> > server. Did you know an existing solution for that? Or is it easier to
> > just write the thing from scratch :)
>
> The store-and-forward part could be email (we know that can be made to
> scale),

An issue with e-mail, as I see it, is that it relies on "polling"
model, while SMS is "push" model in its heart. I don't see a good fit
here, or may be I don't understand your idea.

> Jabber/XMPP (which should scale as well),

Jabber is an interesting idea! The only issue I see is that it
requires a TCP connection for every mobile connected to a BTS, which
could be quite a load.

> AMQP (e.g. RabbitMQ)...

Interesting alternative. I haven't used AMQP yet, but reading about
it, it seems like a viable alternative.

> In all cases we'd need some kind of gateway between that and SIP (or
> OpenBTS); FreeSwitch has some facilities for "chatplans", I haven't played
> with those so I'm don't know whether they can be used for SMS-over-SIP the
> way OpenBTS does it(?).

I think the best way would be to actually embed this into the OpenBTS
itself rather then adding another layer of conversion.

> Also multimedia messages will be a challenge with anything but SMTP
> (email) because of frame size limitations in XMPP and AMQP (although MMS
> might rely on different protocols than SMS -- I sure don't know enough
> GSM to answer that).

Yes, that's definitely a separate story. Lets get our SMS to scale first.

--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru