This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/UmTRX@lists.osmocom.org/.
stephane at shimaore.net stephane at shimaore.netHi 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.