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.