Freeswitch optimization as a registrar
Hi all, I know that freeswitch has not been designed as a pure sip proxy/registrar, but I'm wondering how many subscribers could be handled by FS. I setup the following test environment: - Kamailio 1.4.2 as the registrar - all invite requests are flowing through FS, even for a call between 2 registered subscribers. Many reasons for this: the calls CDR are centralized in the same format, I can easily add a billing ID to a call, proceed to recording, set the caller as anonymous if requested... - FS is used also as a SBC There is still a lot of work to do, mainly on the call forwarding feature and this is why I'm wondering (simply out of curiosity) what could have been achieved using only FS (easier to setup when only one equipment is involved :) ). I'd like to register 40 000 subscribers (if each user registers every 60s, you have approx 670 registration per second, this setup is working on Kamailio). I did the following to increase FS performance regarding registration: - put the directory containing users in a RAMDISK - put the db directory in a RAMDISK with this I was able to reach 190 registration per second (50 without the ramdisk) but for one SIP account, not too useful :p (for your information I see a huge improvement when switching from 1.0.1 phoenix: 150cps to FS svn 105xx: 190) When trying with 25000 SIP accounts, I got no more than 30cps. Then I tried to use the odbc mysql for registration, using this I was able to achieve 50cps. The mysql DB is not in a RAMDISK. For all these tests, the presence support has been disabled. As the IO performance seems to be a bottleneck, I'd like to know if there is a way to store the registration in memory only without database persistency. This thread is there only to share tips, not to complain about FS poor performance as a SIP registrar when compared to Kamailio. If I compare FS to a commercial SBC I'm using in production, I have to say that FS is really a great piece of software (lacks only statistics module, snmp, and heartbeat redundancy for failover). regards, rod
You actually have potentially ~1320 effective "SIP transactions" per second to support 40000 registered ua's with a 60s refresh. This is because the ua sends it's registration refresh unauthenticated. The registrar will then push back an authentication challenge request so the ua can prove its identity, at which point the ua then repeats the same transaction, but with authentication credentials attached. rod wrote:
Hi all,
I know that freeswitch has not been designed as a pure sip proxy/registrar, but I'm wondering how many subscribers could be handled by FS.
I setup the following test environment: - Kamailio 1.4.2 as the registrar - all invite requests are flowing through FS, even for a call between 2 registered subscribers. Many reasons for this: the calls CDR are centralized in the same format, I can easily add a billing ID to a call, proceed to recording, set the caller as anonymous if requested... - FS is used also as a SBC
There is still a lot of work to do, mainly on the call forwarding feature and this is why I'm wondering (simply out of curiosity) what could have been achieved using only FS (easier to setup when only one equipment is involved :) ).
I'd like to register 40 000 subscribers (if each user registers every 60s, you have approx 670 registration per second, this setup is working on Kamailio).
I did the following to increase FS performance regarding registration: - put the directory containing users in a RAMDISK - put the db directory in a RAMDISK
with this I was able to reach 190 registration per second (50 without the ramdisk) but for one SIP account, not too useful :p (for your information I see a huge improvement when switching from 1.0.1 phoenix: 150cps to FS svn 105xx: 190) When trying with 25000 SIP accounts, I got no more than 30cps.
Then I tried to use the odbc mysql for registration, using this I was able to achieve 50cps. The mysql DB is not in a RAMDISK. For all these tests, the presence support has been disabled.
As the IO performance seems to be a bottleneck, I'd like to know if there is a way to store the registration in memory only without database persistency.
This thread is there only to share tips, not to complain about FS poor performance as a SIP registrar when compared to Kamailio. If I compare FS to a commercial SBC I'm using in production, I have to say that FS is really a great piece of software (lacks only statistics module, snmp, and heartbeat redundancy for failover).
regards, rod
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi David, very happy to read you on the FS list! We met in 2001 at OSCon San Diego, where you "infected" me with the telephony virus :-). You did great work with the Bayonne project, really breaking new ground. Thank you, happy hacking, happy new year!!!! Sincerely, Giovanni Maruzzelli ========================================= Company : Celliax Website: www.celliax.org Address : via Pierlombardo 9, 20135 Milano Country/Territory : Italy Business Email: gmaruzz at celliax dot org Cell : 39-347-2665618 Fax : 39-02-87390039 On Tue, Dec 30, 2008 at 2:07 PM, David Sugar <dyfet@gnutelephony.org> wrote:
You actually have potentially ~1320 effective "SIP transactions" per second to support 40000 registered ua's with a 60s refresh. This is because the ua sends it's registration refresh unauthenticated. The registrar will then push back an authentication challenge request so the ua can prove its identity, at which point the ua then repeats the same transaction, but with authentication credentials attached.
rod wrote:
Hi all,
I know that freeswitch has not been designed as a pure sip proxy/registrar, but I'm wondering how many subscribers could be handled by FS.
I setup the following test environment: - Kamailio 1.4.2 as the registrar - all invite requests are flowing through FS, even for a call between 2 registered subscribers. Many reasons for this: the calls CDR are centralized in the same format, I can easily add a billing ID to a call, proceed to recording, set the caller as anonymous if requested... - FS is used also as a SBC
There is still a lot of work to do, mainly on the call forwarding feature and this is why I'm wondering (simply out of curiosity) what could have been achieved using only FS (easier to setup when only one equipment is involved :) ).
I'd like to register 40 000 subscribers (if each user registers every 60s, you have approx 670 registration per second, this setup is working on Kamailio).
I did the following to increase FS performance regarding registration: - put the directory containing users in a RAMDISK - put the db directory in a RAMDISK
with this I was able to reach 190 registration per second (50 without the ramdisk) but for one SIP account, not too useful :p (for your information I see a huge improvement when switching from 1.0.1 phoenix: 150cps to FS svn 105xx: 190) When trying with 25000 SIP accounts, I got no more than 30cps.
Then I tried to use the odbc mysql for registration, using this I was able to achieve 50cps. The mysql DB is not in a RAMDISK. For all these tests, the presence support has been disabled.
As the IO performance seems to be a bottleneck, I'd like to know if there is a way to store the registration in memory only without database persistency.
This thread is there only to share tips, not to complain about FS poor performance as a SIP registrar when compared to Kamailio. If I compare FS to a commercial SBC I'm using in production, I have to say that FS is really a great piece of software (lacks only statistics module, snmp, and heartbeat redundancy for failover).
regards, rod
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Well, there are worse virus's one could be infected with, I suppose ;). Actually recently I had been surviving focusing on secure VoIP and wireless... Giovanni Maruzzelli wrote:
Hi David,
very happy to read you on the FS list!
We met in 2001 at OSCon San Diego, where you "infected" me with the telephony virus :-).
You did great work with the Bayonne project, really breaking new ground.
Thank you,
happy hacking,
happy new year!!!!
Sincerely,
Giovanni Maruzzelli ========================================= Company : Celliax Website: www.celliax.org Address : via Pierlombardo 9, 20135 Milano Country/Territory : Italy Business Email: gmaruzz at celliax dot org Cell : 39-347-2665618 Fax : 39-02-87390039
On Tue, Dec 30, 2008 at 2:07 PM, David Sugar <dyfet@gnutelephony.org> wrote:
You actually have potentially ~1320 effective "SIP transactions" per second to support 40000 registered ua's with a 60s refresh. This is because the ua sends it's registration refresh unauthenticated. The registrar will then push back an authentication challenge request so the ua can prove its identity, at which point the ua then repeats the same transaction, but with authentication credentials attached.
rod wrote:
Hi all,
I know that freeswitch has not been designed as a pure sip proxy/registrar, but I'm wondering how many subscribers could be handled by FS.
I setup the following test environment: - Kamailio 1.4.2 as the registrar - all invite requests are flowing through FS, even for a call between 2 registered subscribers. Many reasons for this: the calls CDR are centralized in the same format, I can easily add a billing ID to a call, proceed to recording, set the caller as anonymous if requested... - FS is used also as a SBC
There is still a lot of work to do, mainly on the call forwarding feature and this is why I'm wondering (simply out of curiosity) what could have been achieved using only FS (easier to setup when only one equipment is involved :) ).
I'd like to register 40 000 subscribers (if each user registers every 60s, you have approx 670 registration per second, this setup is working on Kamailio).
I did the following to increase FS performance regarding registration: - put the directory containing users in a RAMDISK - put the db directory in a RAMDISK
with this I was able to reach 190 registration per second (50 without the ramdisk) but for one SIP account, not too useful :p (for your information I see a huge improvement when switching from 1.0.1 phoenix: 150cps to FS svn 105xx: 190) When trying with 25000 SIP accounts, I got no more than 30cps.
Then I tried to use the odbc mysql for registration, using this I was able to achieve 50cps. The mysql DB is not in a RAMDISK. For all these tests, the presence support has been disabled.
As the IO performance seems to be a bottleneck, I'd like to know if there is a way to store the registration in memory only without database persistency.
This thread is there only to share tips, not to complain about FS poor performance as a SIP registrar when compared to Kamailio. If I compare FS to a commercial SBC I'm using in production, I have to say that FS is really a great piece of software (lacks only statistics module, snmp, and heartbeat redundancy for failover).
regards, rod
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
This is because the ua sends it's registration refresh unauthenticated. The registrar will then push back an authentication challenge request so the ua can prove its identity, at which point the ua then repeats the same transaction, but with authentication credentials attached.
Why does it do that? Every time I do a debug, I see the first request denied as unauthorized and then it always comes right back and gets registered ok. Is it part of the SIP spec to try unauthenticated first? I would think you could set something on the UA to cut out the extra traffic.
Yes, it is part of the SIP specs. BTW, also HTTP works the same way. Sincerely, Giovanni Maruzzelli ========================================= Company : Celliax Website: www.celliax.org Address : via Pierlombardo 9, 20135 Milano Country/Territory : Italy Business Email: gmaruzz at celliax dot org Cell : 39-347-2665618 Fax : 39-02-87390039 On Tue, Dec 30, 2008 at 2:32 PM, peder@networkoblivion.com <peder@networkoblivion.com> wrote:
This is because the ua sends it's registration refresh unauthenticated. The registrar will then push back an authentication challenge request so the ua can prove its identity, at which point the ua then repeats the same transaction, but with authentication credentials attached.
Why does it do that? Every time I do a debug, I see the first request denied as unauthorized and then it always comes right back and gets registered ok. Is it part of the SIP spec to try unauthenticated first? I would think you could set something on the UA to cut out the extra traffic.
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
This is because the ua sends it's registration refresh unauthenticated. The registrar will then push back an authentication challenge request so the ua can prove its identity, at which point the ua then repeats the same transaction, but with authentication credentials attached.
Why does it do that? Every time I do a debug, I see the first request denied as unauthorized and then it always comes right back and gets
Welcome to HTTP Digest authentication. The request has to get challenged to get a new nonce from the server (so as to mitigate replay attacks). You could TLS and auth off of the client cert, except few devices support that, and you'd have the "overhead" of TCP (which is like bad or something). -Michael
I actually have found an alternate approach that we optionally use in sipwitch. Basically, sipwitch can be set to recognize a "trusted" subnet, and automatically accepts a refresh from any actively registered ua on the trusted subnet(s) without requesting an authentication challenge, so long as the ua refreshes from the same sip port and ip address it originally registered and authenticated from. It will also do the same for invites and other otherwise "authentication challenge" sip requests that can originate from ua's on the trusted subnet(s). Using this option of course kills any ability to proxy register multiple ua's through another sip server, although this can be solved by recognizing certain id's as explicitly not trustable. However, for most common configurations and use cases, it works very well and does effectively halve sip network traffic :). Michael Giagnocavo wrote:
This is because the ua sends it's registration refresh unauthenticated. The registrar will then push back an authentication challenge request so the ua can prove its identity, at which point the ua then repeats the same transaction, but with authentication credentials attached. Why does it do that? Every time I do a debug, I see the first request denied as unauthorized and then it always comes right back and gets
Welcome to HTTP Digest authentication. The request has to get challenged to get a new nonce from the server (so as to mitigate replay attacks).
You could TLS and auth off of the client cert, except few devices support that, and you'd have the "overhead" of TCP (which is like bad or something).
-Michael
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
What revision of FreeSWITCH are you trying with? I would try with current trunk, I have a suspicion we fixed the main issue your running into. Mike On Dec 30, 2008, at 7:21 AM, rod wrote:
Hi all,
I know that freeswitch has not been designed as a pure sip proxy/registrar, but I'm wondering how many subscribers could be handled by FS.
I setup the following test environment: - Kamailio 1.4.2 as the registrar - all invite requests are flowing through FS, even for a call between 2 registered subscribers. Many reasons for this: the calls CDR are centralized in the same format, I can easily add a billing ID to a call, proceed to recording, set the caller as anonymous if requested... - FS is used also as a SBC
There is still a lot of work to do, mainly on the call forwarding feature and this is why I'm wondering (simply out of curiosity) what could have been achieved using only FS (easier to setup when only one equipment is involved :) ).
I'd like to register 40 000 subscribers (if each user registers every 60s, you have approx 670 registration per second, this setup is working on Kamailio).
I did the following to increase FS performance regarding registration: - put the directory containing users in a RAMDISK - put the db directory in a RAMDISK
with this I was able to reach 190 registration per second (50 without the ramdisk) but for one SIP account, not too useful :p (for your information I see a huge improvement when switching from 1.0.1 phoenix: 150cps to FS svn 105xx: 190) When trying with 25000 SIP accounts, I got no more than 30cps.
Then I tried to use the odbc mysql for registration, using this I was able to achieve 50cps. The mysql DB is not in a RAMDISK. For all these tests, the presence support has been disabled.
As the IO performance seems to be a bottleneck, I'd like to know if there is a way to store the registration in memory only without database persistency.
This thread is there only to share tips, not to complain about FS poor performance as a SIP registrar when compared to Kamailio. If I compare FS to a commercial SBC I'm using in production, I have to say that FS is really a great piece of software (lacks only statistics module, snmp, and heartbeat redundancy for failover).
regards, rod
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi, I upgraded today to 10999 with same results. rod. Michael Jerris wrote:
What revision of FreeSWITCH are you trying with? I would try with current trunk, I have a suspicion we fixed the main issue your running into.
Mike
On Dec 30, 2008, at 7:21 AM, rod wrote:
Hi all,
I know that freeswitch has not been designed as a pure sip proxy/registrar, but I'm wondering how many subscribers could be handled by FS.
I setup the following test environment: - Kamailio 1.4.2 as the registrar - all invite requests are flowing through FS, even for a call between 2 registered subscribers. Many reasons for this: the calls CDR are centralized in the same format, I can easily add a billing ID to a call, proceed to recording, set the caller as anonymous if requested... - FS is used also as a SBC
There is still a lot of work to do, mainly on the call forwarding feature and this is why I'm wondering (simply out of curiosity) what could have been achieved using only FS (easier to setup when only one equipment is involved :) ).
I'd like to register 40 000 subscribers (if each user registers every 60s, you have approx 670 registration per second, this setup is working on Kamailio).
I did the following to increase FS performance regarding registration: - put the directory containing users in a RAMDISK - put the db directory in a RAMDISK
with this I was able to reach 190 registration per second (50 without the ramdisk) but for one SIP account, not too useful :p (for your information I see a huge improvement when switching from 1.0.1 phoenix: 150cps to FS svn 105xx: 190) When trying with 25000 SIP accounts, I got no more than 30cps.
Then I tried to use the odbc mysql for registration, using this I was able to achieve 50cps. The mysql DB is not in a RAMDISK. For all these tests, the presence support has been disabled.
As the IO performance seems to be a bottleneck, I'd like to know if there is a way to store the registration in memory only without database persistency.
This thread is there only to share tips, not to complain about FS poor performance as a SIP registrar when compared to Kamailio. If I compare FS to a commercial SBC I'm using in production, I have to say that FS is really a great piece of software (lacks only statistics module, snmp, and heartbeat redundancy for failover).
regards, rod
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
If your not using sqlite, make sure to create indexes on the tables created, you should be able to grep the ones we do in sqlite out of the code. Mike On Dec 30, 2008, at 9:59 AM, rod wrote:
Hi,
I upgraded today to 10999 with same results.
rod.
Michael Jerris wrote:
What revision of FreeSWITCH are you trying with? I would try with current trunk, I have a suspicion we fixed the main issue your running into.
Mike
On Dec 30, 2008, at 7:21 AM, rod wrote:
Hi all,
I know that freeswitch has not been designed as a pure sip proxy/registrar, but I'm wondering how many subscribers could be handled by FS.
I setup the following test environment: - Kamailio 1.4.2 as the registrar - all invite requests are flowing through FS, even for a call between 2 registered subscribers. Many reasons for this: the calls CDR are centralized in the same format, I can easily add a billing ID to a call, proceed to recording, set the caller as anonymous if requested... - FS is used also as a SBC
There is still a lot of work to do, mainly on the call forwarding feature and this is why I'm wondering (simply out of curiosity) what could have been achieved using only FS (easier to setup when only one equipment is involved :) ).
I'd like to register 40 000 subscribers (if each user registers every 60s, you have approx 670 registration per second, this setup is working on Kamailio).
I did the following to increase FS performance regarding registration: - put the directory containing users in a RAMDISK - put the db directory in a RAMDISK
with this I was able to reach 190 registration per second (50 without the ramdisk) but for one SIP account, not too useful :p (for your information I see a huge improvement when switching from 1.0.1 phoenix: 150cps to FS svn 105xx: 190) When trying with 25000 SIP accounts, I got no more than 30cps.
Then I tried to use the odbc mysql for registration, using this I was able to achieve 50cps. The mysql DB is not in a RAMDISK. For all these tests, the presence support has been disabled.
As the IO performance seems to be a bottleneck, I'd like to know if there is a way to store the registration in memory only without database persistency.
This thread is there only to share tips, not to complain about FS poor performance as a SIP registrar when compared to Kamailio. If I compare FS to a commercial SBC I'm using in production, I have to say that FS is really a great piece of software (lacks only statistics module, snmp, and heartbeat redundancy for failover).
regards, rod
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (6)
-
David Sugar
-
Giovanni Maruzzelli
-
Michael Giagnocavo
-
Michael Jerris
-
peder＠networkoblivion.com
-
rod