New blog article: Kamailio as an SBC - five years on
This is an update to my 2013-era article on the subject, and thought it might be of interest to some of you: http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/ -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hey Alex As you well know i have been working on a platform, and started off using Kamailio as my edge proxy, but was pragmatically forced to pivot to OpenSIPS as it could do more SBC-flavored things, which it seems the Kamailio community find less than savory. Of major note is the mid-registrar module, which allowed for short-re-reg intervals on the outside for nat traversal, with long core intervals to alleviate load, while also exposing a directly adjacent contact to the core switch without the need for the core to support such esoteric measures as the path header. This is crucial when supporting commercial registrars such as broadsoft or a metaswitch (and to a lesser extent freeswitch which only KINDA supports path) which are written expecting the commercial SBC behavior of adjacent contacts. Abandoning SIP over UDP is a major topic for me these days. Once upon a time SBC's were a great place to prune packets to limbo under the 1500 byte MTU bar, but as we all know this is a losing battle with the bloating of SDP's and the supported header, and can cause random breakage. Furthermore with the internet at large becoming increasingly hostile towards UDP as a transport due to the massive DDOS possibilities many UDP protocols offer, the sip over udp client space is becoming increasingly difficult. Moving access-side to TCP offers literally nothing but upside, with one exception, failover, as you well identified. Of course an open-source SBC in software carried with it the possibility for automation and orchestration, and if you go TCP, then there's literally no excuse to not encrypt everywhere and go TLS with LetsEncrypt. TLS signaling also carries the benefit of carving through ALG's and anti-competitive ISP practices. Im still a proponent of UDP in the core, where jumbo-framing can be guaranteed, as it allows for easier fail-over of core elements mid-dialogue, and eliminates cumbersome state tracking inside a trusted core. In my commercial practice i still support both big-iron commercial SBC's as well as the FOSS sort. Long term, FOSS will win. Its inevitable but it wont come until an industry paradigm shift from screen watching NOC engineers to automation building DevOps takes place. On 6/18/2018 10:20 PM, Alex Balashov wrote:
This is an update to my 2013-era article on the subject, and thought it might be of interest to some of you:
http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/
Ryan, Thanks for your feedback! See inline: On Tue, Jun 19, 2018 at 12:20:40PM -0700, Ryan Delgrosso wrote:
As you well know i have been working on a platform, and started off using Kamailio as my edge proxy, but was pragmatically forced to pivot to OpenSIPS as it could do more SBC-flavored things, which it seems the Kamailio community find less than savory.
Some and not others.
Of major note is the mid-registrar module, which allowed for short-re-reg intervals on the outside for nat traversal, with long core intervals to alleviate load, while also exposing a directly adjacent contact to the core switch without the need for the core to support such esoteric measures as the path header. This is crucial when supporting commercial registrars such as broadsoft or a metaswitch (and to a lesser extent freeswitch which only KINDA supports path) which are written expecting the commercial SBC behavior of adjacent contacts.
Indeed, and I made mention in the article. I have reason to believe Kamailio will have a comparable solution in the foreseeable future.
Abandoning SIP over UDP is a major topic for me these days. Once upon a time SBC's were a great place to prune packets to limbo under the 1500 byte MTU bar, but as we all know this is a losing battle with the bloating of SDP's and the supported header, and can cause random breakage. Furthermore with the internet at large becoming increasingly hostile towards UDP as a transport due to the massive DDOS possibilities many UDP protocols offer, the sip over udp client space is becoming increasingly difficult. Moving access-side to TCP offers literally nothing but upside, with one exception, failover, as you well identified. Of course an open-source SBC in software carried with it the possibility for automation and orchestration, and if you go TCP, then there's literally no excuse to not encrypt everywhere and go TLS with LetsEncrypt. TLS signaling also carries the benefit of carving through ALG's and anti-competitive ISP practices.
I don't think most of the ITSP industry has moved to that insight yet, although anecdotally, it appears that the metastasis of increasingly tenacious ALGs is creating a NAT support crisis.
Im still a proponent of UDP in the core, where jumbo-framing can be guaranteed, as it allows for easier fail-over of core elements mid-dialogue, and eliminates cumbersome state tracking inside a trusted core.
I would agree with that. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
PS. What is this about FreeSWITCH "kind of" supporting Path? I use it and it works just fine. Am I missing something? -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
mod_sms is only loosely bolted onto sofia here, and doesn't take any hints on behavior from the path header. If you wish the expose or engage in SIMPLE flows for text messaging etc the path header breaks your world. Overtures to freeswitch here were met with a cursory 6 figure quote as its apparently non-trivial to fix. On 6/19/2018 12:26 PM, Alex Balashov wrote:
PS.
What is this about FreeSWITCH "kind of" supporting Path? I use it and it works just fine. Am I missing something?
On 6/19/2018 12:24 PM, Alex Balashov wrote:
Abandoning SIP over UDP is a major topic for me these days. Once upon a time SBC's were a great place to prune packets to limbo under the 1500 byte MTU bar, but as we all know this is a losing battle with the bloating of SDP's and the supported header, and can cause random breakage. Furthermore with the internet at large becoming increasingly hostile towards UDP as a transport due to the massive DDOS possibilities many UDP protocols offer, the sip over udp client space is becoming increasingly difficult. Moving access-side to TCP offers literally nothing but upside, with one exception, failover, as you well identified. Of course an open-source SBC in software carried with it the possibility for automation and orchestration, and if you go TCP, then there's literally no excuse to not encrypt everywhere and go TLS with LetsEncrypt. TLS signaling also carries the benefit of carving through ALG's and anti-competitive ISP practices. I don't think most of the ITSP industry has moved to that insight yet, although anecdotally, it appears that the metastasis of increasingly tenacious ALGs is creating a NAT support crisis.
Worth noting here that i think its going to be regulatory issues that force this first on the peering side with SHAKEN/STIR (somewhat forced acronyms) advocating the cryptographic signing of invites at the hop-on point. This is pretty much guarenteed to break most current peering relationships and force carriers into at minimum TCP to support the signature payloads. Getting a handle on moving to TCP/TLS now will simply make you more effective when the inevitable happens. FWIW I fully support signing of invites and identity headers, but the proposals in SHAKEN/STIR i think are barking up an unsustainable bureaucracy tree that makes me want to watch Brazil.
On Tue, Jun 19, 2018 at 01:03:18PM -0700, Ryan Delgrosso wrote:
FWIW I fully support signing of invites and identity headers, but the proposals in SHAKEN/STIR i think are barking up an unsustainable bureaucracy tree that makes me want to watch Brazil.
Yup. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hello, On 19.06.18 21:20, Ryan Delgrosso wrote:
[...]
Of major note is the mid-registrar module, which allowed for short-re-reg intervals on the outside for nat traversal, with long core intervals to alleviate load, while also exposing a directly adjacent contact to the core switch without the need for the core to support such esoteric measures as the path header. This is crucial when supporting commercial registrars such as broadsoft or a metaswitch (and to a lesser extent freeswitch which only KINDA supports path) which are written expecting the commercial SBC behavior of adjacent contacts. The uac module of Kamailio has support for doing remote registrations for very long time (first added in v3.1.0, in 2010). There are plenty of options to control if the registration done downstream differs in terms of expire from the one received from downstream, when to enable/disable these registrations, etc... The usual register/usrloc track the incoming register requests, uac manage outgoing register requests. It might be what you are looking for.
Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com
On Wed, Jun 20, 2018 at 09:33:49AM +0200, Daniel-Constantin Mierla wrote:
The uac module of Kamailio has support for doing remote registrations for very long time (first added in v3.1.0, in 2010). There are plenty of options to control if the registration done downstream differs in terms of expire from the one received from downstream, when to enable/disable these registrations, etc...
Oh really? The UAC module supports some method of correlating incoming registrations to outgoing ones? I did not know this. This might call for an update of the article! -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
On 20.06.18 09:33, Alex Balashov wrote:
On Wed, Jun 20, 2018 at 09:33:49AM +0200, Daniel-Constantin Mierla wrote:
The uac module of Kamailio has support for doing remote registrations for very long time (first added in v3.1.0, in 2010). There are plenty of options to control if the registration done downstream differs in terms of expire from the one received from downstream, when to enable/disable these registrations, etc... Oh really? The UAC module supports some method of correlating incoming registrations to outgoing ones? I did not know this. This might call for an update of the article!
Not sure what you really expect by "correlating" here, but if it is about enabling the registration downstream when processing the one from upstream, then it is something like: save("location"); if(registered("location", "$tu")) { ??? # user online, enable its uac reg record ??? jsonrpc_exec('{"jsonrpc": "2.0", "method": "uac.reg_enable", "params": ["l_username", "$tU"], "id": 1}'); } else { ??? # user online, enable its uac reg record ??? jsonrpc_exec('{"jsonrpc": "2.0", "method": "uac.reg_disable", "params": ["l_username", "$tU"], "id": 1}'); } Correlation can be done on couple of fields, like local user, remote user, local unique id, ... I used for very long time the uac module to do registrations to downstream servers and handle the ones from devices locally in kamailio edge proxy, with different expires values, etc ... that was the reason I added this feature many years ago and, iirc, it was first out there offering such thing in a proxy. Typically I do not enable/disable on register/unregister from UA, letting the downstream server believe the user is always online, so it routes back to kamailio proxy and then decide what to do if the user is offline, like sending to a dedicated announcement server or forward to pstn/gsm, ... I though of adding dedicated cfg functions to enable/disable uac_reg records, but given that rpc commands can be executed with jsonrpc_exec() at low expense, those got somehow lower priority. This feature of uac module got contributions from other devs, so it is used quite a lot out there. Of course, maybe some scenarios are not covered in an easy mode, but nobody asked new stuff on this part -- anyhow, we have the sources, other enhancements can be added if people find something that needs to be simplified or some use cases need to be addressed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com
Thank you, Daniel. That was insightful, and definitely something of which I had not thought. I updated the article accordingly: http://www.evaristesys.com/blog/kamailio-as-an-sbc-five-years-on/ -- Alex On Wed, Jun 20, 2018 at 10:00:05AM +0200, Daniel-Constantin Mierla wrote:
On 20.06.18 09:33, Alex Balashov wrote:
On Wed, Jun 20, 2018 at 09:33:49AM +0200, Daniel-Constantin Mierla wrote:
The uac module of Kamailio has support for doing remote registrations for very long time (first added in v3.1.0, in 2010). There are plenty of options to control if the registration done downstream differs in terms of expire from the one received from downstream, when to enable/disable these registrations, etc... Oh really? The UAC module supports some method of correlating incoming registrations to outgoing ones? I did not know this. This might call for an update of the article!
Not sure what you really expect by "correlating" here, but if it is about enabling the registration downstream when processing the one from upstream, then it is something like:
save("location");
if(registered("location", "$tu")) { ??? # user online, enable its uac reg record ??? jsonrpc_exec('{"jsonrpc": "2.0", "method": "uac.reg_enable", "params": ["l_username", "$tU"], "id": 1}'); } else { ??? # user online, enable its uac reg record ??? jsonrpc_exec('{"jsonrpc": "2.0", "method": "uac.reg_disable", "params": ["l_username", "$tU"], "id": 1}'); }
Correlation can be done on couple of fields, like local user, remote user, local unique id, ...
I used for very long time the uac module to do registrations to downstream servers and handle the ones from devices locally in kamailio edge proxy, with different expires values, etc ... that was the reason I added this feature many years ago and, iirc, it was first out there offering such thing in a proxy.
Typically I do not enable/disable on register/unregister from UA, letting the downstream server believe the user is always online, so it routes back to kamailio proxy and then decide what to do if the user is offline, like sending to a dedicated announcement server or forward to pstn/gsm, ...
I though of adding dedicated cfg functions to enable/disable uac_reg records, but given that rpc commands can be executed with jsonrpc_exec() at low expense, those got somehow lower priority. This feature of uac module got contributions from other devs, so it is used quite a lot out there. Of course, maybe some scenarios are not covered in an easy mode, but nobody asked new stuff on this part -- anyhow, we have the sources, other enhancements can be added if people find something that needs to be simplified or some use cases need to be addressed.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com
-- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
participants (3)
-
abalashov＠evaristesys.com -
miconda＠gmail.com -
ryandelgrosso＠gmail.com