27 Mar
2013
27 Mar
'13
5:19 p.m.
Hi Stephane,
On Wed, Mar 6, 2013 at 4:20 AM, <stephane(a)shimaore.net> wrote:
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
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. 
27 Mar
27 Mar
6:30 p.m.
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.
13 Apr
13 Apr
11:31 a.m.
Stephane,
Sorry for slow response.
On Wed, Mar 27, 2013 at 9:30 PM, <stephane(a)shimaore.net> wrote:
Thank you for the information!
Now we just have to implement that :)
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.
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),
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
11:49 a.m.
Stephane,
On Wed, Mar 27, 2013 at 9:30 PM, <stephane(a)shimaore.net> wrote:
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
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).
4:55 p.m.
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.
5:10 p.m.
On Sat, Apr 13, 2013 at 6:55 PM, <stephane(a)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.
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
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).
5:22 p.m.
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.
14 Apr
14 Apr
1:05 p.m.
On Sat, Apr 13, 2013 at 7:22 PM, <stephane(a)shimaore.net> wrote:
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
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
1:31 p.m.
On Sun, Apr 14, 2013 at 3:05 PM, Alexander Chemeris
<alexander.chemeris(a)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
4035
days inactive
4053
days old
8 comments
2 participants
participants (2)
-
Alexander Chemeris -
stephane＠shimaore.net