Stephane,
Sorry for slow response.
On Wed, Mar 27, 2013 at 9:30 PM, stephane@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