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

stephane at shimaore.net stephane at shimaore.net
Wed Mar 27 17:30:46 UTC 2013


Hi Alexander,

> 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).

> 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), Jabber/XMPP (which should scale as well), AMQP (e.g.
RabbitMQ)...
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(?).

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).
S.




More information about the UmTRX mailing list