Hi Stephane,
On Wed, Mar 6, 2013 at 4:20 AM, stephane@shimaore.net wrote:
Thank you for your patch to make it working with OpenSIPS :) Looking forward for more contributions to the SIP side of things.
My line of thought is to use OpenSIPS as registrar, with a Redis backend. Then use OpenSIPS to route calls, SMS, .. based on the IMSI.
It seems that using OpenSIPS as much as possible is a good way for scalability, instead of trying to get Freeswitch to scale. At least that's what I was suggested. So I wonder what we could actually offload to OpenSIPS.
Do you think we could use OpenSIPS not only as a registrar, but also as an authentication server?
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.
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 :)
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
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.
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
Stephane,
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).
Yes, registrar is doing authentication in the case of OpenBTS as well.
Btw, did you look at Kamailio which merged OpenIMS developments some time ago?
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
Alexander,
Btw, did you look at Kamailio which merged OpenIMS developments some time ago?
No I hadn't. Now that I have, I wished I didn't. IMS sure looks like a good barrier to entry. There's more to it than the proxy though (call continuity / handover requires B2BUA from what I just read, which makes sense).
[SMS]
An issue with e-mail, as I see it, is that it relies on "polling" model, while SMS is "push" model in its heart.
Good point; again, my limited knowledge of GSM tech in play.
Jabber is an interesting idea! The only issue I see is that it requires a TCP connection for every mobile connected to a BTS [...]
Not if you use a Jabber chatroom, but in that case you're better off using AMQP anyhow since it really is a machine-to-machine alternative.
My understanding of AMQP is that you can subscribe to multiple queues over a single connection so that should scale OK. (Based on my limited experience with node-amqp.) S.
On Sat, Apr 13, 2013 at 6:55 PM, stephane@shimaore.net wrote:
Btw, did you look at Kamailio which merged OpenIMS developments some time ago?
No I hadn't. Now that I have, I wished I didn't. IMS sure looks like a good barrier to entry. There's more to it than the proxy though (call continuity / handover requires B2BUA from what I just read, which makes sense).
Could you point me to a place where you found description of call continuity / handover in IMS? When I did a quick search I didn't find it.
Good point about IMS is that it's the standard for VoLTE and thus having OpenBTS compatible with IMS will make it easier to integrate with LTE networks.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
Could you point me to a place where you found description of call continuity / handover in IMS? When I did a quick search I didn't find it.
I read mostly the article on VCC here: http://catis-blog.com/?tag=as
Pages 236-237 of this Tekelec presentation have call flows: http://www.iptel.org/files/sip_tutorial.pdf
S.
On Sat, Apr 13, 2013 at 7:22 PM, stephane@shimaore.net wrote:
Could you point me to a place where you found description of call continuity / handover in IMS? When I did a quick search I didn't find it.
I read mostly the article on VCC here: http://catis-blog.com/?tag=as
Very nice description of IMS concepts. Do you know the author by a chance?
Unfortunately, VCC is mostly focused on CS-IMS call flows which are not interesting for us, because in the OpenBTS architecture there are no CS calls at the core network. In general, we don't need CS interoperability part of IMS which is the ugliest part of it.
IMS have nice concepts and logic behind it, but we should adopt it with creativity. My thoughts after reading that blog:
1. We could think about OpenBTS as a P-CSCF. There will be another P-CSCF(s) when we start connecting to other networks and implement roaming, but for a standalone network OpenBTS's are the only P-CSCFs. They could route SIP messages to a proper next CSCF, which could be different for different IMSIs and different SIP message types.
2. I-CSCF is what handles authentication and admission control, which is important when our subscribers roam and connect from other networks. For internal calls I-CSCF functions could be reduced or even completely split between other elements of a network. Or we could keep it for balancing or other purposes.
3. S-CSCF in IMS somehow combines proxy and registrar, which might be better to keep separate. I don't see a problem if OpenSIPS/Kamailio could serve as such a combined entity already, otherwise it would be easier to get the thing in pieces.
4. IMS defines a way to dynamically define triggering points (Initial Filter Criteria aka iFC) which tells a CSCF to route call one or another way. I believe we don't need this initially and could live with OpenSIPS/Kamailio configs. And later we could figure out whether iFC is needed at all or there are better ways to handle events, e.g. http://switchcoder.fairwaves.ru/
5. HSS is a part we really need to have. The only viable open-source alternative I know of is a Mobicents Diameter solution. Have you ever played with it or at least with Java SLEE in general? It looks awful to me, but some people like it :)
6. SMSC isn't really specified in IMS tutorials I saw. Do they assume it's just one of Aplication Servers? We could use Mobicents SMSC (https://code.google.com/p/smscgateway/) with a SIP frontend and keep SIP/IMS architecture or we could use AMQP as we discussed earlier.
And surely we could avoid using all those ugly abbreviations when we talk about OpenBTS network. It's enough to keep a kind of mapping documented.
All that said, the biggest problem right now is to have scalable SMSC and registration/authentication. Everything else is a lesser issue.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
On Sun, Apr 14, 2013 at 3:05 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
All that said, the biggest problem right now is to have scalable SMSC and registration/authentication. Everything else is a lesser issue.
One more issue is billing support. On one hand, we want to decentralize the system as much as possible, but on the other hand we must support real-time billing. For OpenBTS we don't need a media proxy to provide real-time billing, because we OpenBTS is a trusted controlled entity. But there should be support for SIP keep-alives to prevent endless calls in case of a network fail between an OpenBTS and an billing point.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
-
Alexander Chemeris -
stephane＠shimaore.net