TUTORIAL Mid-call Mobility aka Handover, Handoff.

[chris_c_]

SCENARIO:

You're in a call on your VOIP soft phone app running on your smartphone, connected to your Asterisk 13+ PBX, which happens to be managed by incredible pbx 12+ or freepbx 12+.

You start out the call, connected on WiFi at your workplace. It's an important business call.

You're on the move, walking out of your workplace, out of range, your phone falls back to 4G LTE data connection. You're still on the call, still talking business.

You arrive at your destination, the local burger brew pub with an awesome 50 megabit free WiFi, and your smart phone auto connects. You're still on the call, conversation is flowing, no interruptions, aside from the one second break when your call switched to a new WiFi internet connection!

You'd really like your VOIP PBX call to stay up and connected THE ENTIRE TIME, just like a mobile GSM phone does. Yes, even when your smartphone roams from your office WiFi, to 4G LTE, to a different WiFi network at the restaurant or other public free WiFi.

I've got this running in real life, it works great.

HOW TO DO THIS:

Smartphone = standard iPhone 6 subscribed on 4G LTE. Should work fine on Android phone!
VOIP app = Linphone.
iPhone App store
Android Google Play store
VOIP app Account settings = Transport TCP, STUN server stun.counterpath.net, ICE ON.
PBX = incredible PBX 12 (yes it's a version behind, yet it's OK) + Asterisk 13.22.0 + GVSIP patch.
PBX trunk used = GVSIP (shouldn't matter however).
Asterisk SIP Settings = STUN server stun.counterpath.net
Asterisk Extension settings for the extension used by the VOIP app = use PJSIP, Enable ICE support = Yes.
PBX Firewall IPTABLES status = OFF **

** Turning off the IPTABLES Firewall off is an issue. However, it's required to get this mid-call mobility to work. Why? As soon as WiFi connection drops, the VOIP app will try to reconnect your active call over 4G LTE data connection, on an IP address that has never been seen before by your PBX's IPTABLES firewall, so then obviously it's never been added to the whitelist maintained by IPTABLES and PORT KNOCKING. So this reconnection would fail. So the iptables firewall must be down and allow in your VOIP app's re-connection.

With the iptables firewall ON, your mid-call mobility will FAIL, due to the fact your 4G LTE IP address is not whitelisted by the highly paranoid iptables firewall running on the ipbx/freepbx asterisk PBX server!

For the purpose of this demonstration, iptables is disabled, and mid-call mobility works GREAT.


WHAT'S NEXT
The true fix is to upgrade the iptables technology, and come up with a more forgiving iptables firewall so that mid-call mobility can work WHILE THE FIREWALL is running normally and protecting you against hackers, thieves, etc. The iptables running on the PBX must accept IP connections from ANY IP address, yet ONLY FOR THE PURPOSES of reconnecting the call, to achieve mid-call mobility.

@billsimon @wardmundy @jerrm @tycho @kenn10

 

[shetu]

We are waiting...

 

[wardmundy]

Only way I can think of is to expose UDP 5060 or 5061 and then you have the dangerous PBX from yesteryear.

 

[chris_c_]

Only way I can think of is to expose UDP 5060 or 5061 and then you have the dangerous PBX from yesteryear.

We could allow by MAC Addresses we've seen before and which have successfully logged in.
"Familiar MAC Address"
Now, MAC Address can be forged easily on some operating systems ie Windows Android Linux, so it's not 100% trustworthy in terms of identity, it's only a temporary pass to let them try to login on this New IP address.
The "Familiar MAC Address" allows the IP the opportunity to log in X number times, as normal.
Any failed login after X number of times, would still be treated as a hacker and we add a fail2ban block on that IP with standard policy, that IP is banned for X minutes after which it can retry login from that IP (as long as it has a familiar MAC Address).

IMO this should be secure enough to prevent brute force attempts to guess a billion passwords on a wide open ports 5060 and 50601 without limit over the course of months until they find something.

Thoughts?

 

[billsimon]

Do you know of any clients except linphone? I was disappointed that this doesn't seem to work with GS Wave.

 

[jerrm]

We could allow by MAC Addresses we've seen before and which have successfully logged in.

For routed traffic? How?

 

[chris_c_]

Do you know of any clients except linphone? I was disappointed that this doesn't seem to work with GS Wave.

1. We can try other free SIP client smart phone apps. Some good ones to try are Zoiper, Android SIP Client, CSipSimple, SipDroid, Bria (X-Lite) apps. Try and post back your results here!
2. If you're in love with GS Wave and want to continue using it, I understand, you should tell your GrandStream rep to have their devs check out the github of Linphone, and read the code related to handling the SIP REFER message, for the purpose of learning how to add SIP Mid-Call Mobility to their GS Wave VOIP SIP app. They can also pay the makers of Linphone to add the relevant code to the next version of the new and improved GS Wave.

 

[wardmundy]

We could allow by MAC Addresses we've seen before and which have successfully logged in.
"Familiar MAC Address"
Now, MAC Address can be forged easily on some operating systems ie Windows Android Linux, so it's not 100% trustworthy in terms of identity, it's only a temporary pass to let them try to login on this New IP address.
The "Familiar MAC Address" allows the IP the opportunity to log in X number times, as normal.
Any failed login after X number of times, would still be treated as a hacker and we add a fail2ban block on that IP with standard policy, that IP is banned for X minutes after which it can retry login from that IP (as long as it has a familiar MAC Address).

IMO this should be secure enough to prevent brute force attempts to guess a billion passwords on a wide open ports 5060 and 50601 without limit over the course of months until they find something.

Thoughts?

Correct me if I'm mistaken, but I didn't think MAC addresses were routable.

 

[chris_c_]

For routed traffic? How?

My bad. While the mobile smartphone is on a remote subnet (4G LTE or WiFi network), its MAC address isn't visible to iptables on Asterisk PBX. So, scratch that idea of "Familiar MAC Addresses"...

 

[jerrm]

The iptables firewall (or other firewall related software) would need to save a list of "Familiar MAC Addresses" which are MAC Addresses that are associated with IP addresses that are allowed thru the firewall, either by port knock, or whitelist.
These "Familiar MAC Addresses" will be allowed to thru the SIP ports specified in Asterisk for the SIP protocols DTLS UDP TCP and TLS, and allowed to communicate from ANY IP4 or IP6 Address.

Again, how? MACs aren't in routed traffic. I guess technically they are, as part of the Ethernet frame, but it would always be the next in line router, which means you match everything.

 

[chris_c_]

The freepbx "Responsive Firewall" module from GitHub should allow this mid-call mobility to work.

"When Responsive is enabled, any signalling packet that comes from a host that the server doesn't know about, and that would normally be rejected, is instead tentatively allowed through the firewall. If, after a small number of packets, the machine that is sending the signalling packets has not registered successfully, all signalling traffic from that client is DROP'ed for a short period of time (60 seconds).

If the remote CONTINUES to send traffic without successfully registering, that IP address is blocked for at least 24 hours, and the block isn't dropped until the remote machine has not sent any packets for 24 hours."​

It's an AGPLv3+ module available on github.

 

[chris_c_]

Again, how? MACs aren't in routed traffic. I guess technically they are, as part of the Ethernet frame, but it would always be the next in line router, which means you match everything.

You're right, this MAC idea wouldn't work. Looks like only a "Responsive Firewall", such as the freepbx GPL github module, would work. It allows all traffic from an IP for 10 SIP signalling packets, if not logged in successfully at that point, temporarily DROPs packets for 60 seconds, etc, etc. Seems to be relaxed enough to allow mid-call mobility, yet tight enough to prevent brute force hackers.

 

[billsimon]

1. We can try other free SIP client smart phone apps. Some good ones to try are Zoiper, Android SIP Client, CSipSimple, SipDroid, Bria (X-Lite) apps. Try and post back your results here!
2. If you're in love with GS Wave and want to continue using it, I understand, you should tell your GrandStream rep to have their devs check out the github of Linphone, and read the code related to handling the SIP REFER message, for the purpose of learning how to add SIP Mid-Call Mobility to their GS Wave VOIP SIP app. They can also pay the makers of Linphone to add the relevant code to the next version of the new and improved GS Wave.

REFER? Are you sure? That's used for call forwarding or redirection. I would think the appropriate method would be a new INVITE using the known Call-ID to re-establish the signaling path and the media path.

 

[chris_c_]

REFER? Are you sure? That's used for call forwarding or redirection. I would think the appropriate method would be a new INVITE using the known Call-ID to re-establish the signaling path and the media path.

I misspoke, I think you're right. There's about 6 methods of doing this mid-call mobility. The SIP messages used are mostly REGISTER, INVITE, RE-INVITE (same CALLERID and FROM headers), SDP to stop and re-start the audio media flow.

 

[jerrm]

The freepbx "Responsive Firewall" module from GitHub should allow this mid-call mobility to work.

"When Responsive is enabled, any signalling packet that comes from a host that the server doesn't know about, and that would normally be rejected, is instead tentatively allowed through the firewall. If, after a small number of packets, the machine that is sending the signalling packets has not registered successfully, all signalling traffic from that client is DROP'ed for a short period of time (60 seconds).

If the remote CONTINUES to send traffic without successfully registering, that IP address is blocked for at least 24 hours, and the block isn't dropped until the remote machine has not sent any packets for 24 hours."​

It's an AGPLv3+ module available on github.

Just skimming GitHub, so I may have missed something, but a core component - hooks/voipfirewalld only appears to exist as a blob with no source. Appears to be some sort of encrypted/obfuscated php. Doesn't bode well if not on a Redhat/CentOS derived system.

 

[chris_c_]

Just skimming GitHub, so I may have missed something, but a core component - hooks/voipfirewalld only appears to exist as a blob with no source. Appears to be some sort of encrypted/obfuscated php. Doesn't bode well if not on a Redhat/CentOS derived system.

It appears to be a PHAR (php archive) format file. There's a good chance it can be uncompressed to normal source code files.

 

[chris_c_]

Just skimming GitHub, so I may have missed something, but a core component - hooks/voipfirewalld only appears to exist as a blob with no source. Appears to be some sort of encrypted/obfuscated php. Doesn't bode well if not on a Redhat/CentOS derived system.

The source code for voipfirewalld is available in clear text on github and is GPL.
They use a build script to create the voipfirewalld phar.
The purpose of the PHAR archive appears to be to keep the code together in one file and run more efficiently as it's running as some sort of daemon service so this is best for performance.
The dev work is already done, it works, no need to reinvent the wheel from scratch.
Someone should try and install and run the freepbx firewall github module in responsive mode.
:~# gpldownload firewall

 

[jerrm]

The source code for voipfirewalld is available in clear text on github and is GPL.
The dev work is already done, it works, no need to reinvent the wheel.
Someone should try and install and run the freepbx firewall github module in responsive mode.
:~# gpldownload firewall

Yeah, I had already looked at it. When you factor out all the "we have to support anything the user has done to the system" stuff, the core looks very simple, monitor AMI events, add to white/gray/blacklists as appropriate. Haven't looked at the generated rules, but at first glance it appears iptables recent is doing most of the timeout work.

Pretty darn close to some of the stuff we do - convergent evolution.

Nice that it is all bundled up in a publicly accessible way, but nothing groundbreaking.

 

[chris_c_]

Yeah, I had already looked at it. When you factor out all the "we have to support anything the user has done to the system" stuff, the core looks very simple, monitor AMI events, add to white/gray/blacklists as appropriate. Haven't looked at the generated rules, but at first glance it appears iptables recent is doing most of the timeout work.

Pretty darn close to some of the stuff we do - convergent evolution.

Nice that it is all bundled up in a publicly accessible way, but nothing groundbreaking.

So, what this means is, someone should do comparative analysis of the code in the PIAF firewall + the previously mentioned "iptables recent" voip firewall rule hacks, and this freepbx responsive firewall GPL module, and possibly some other asterisk iptables voip firewall rules. Whichever setup works best to allow for effortless roaming mobile smartphones to achieve mid-call mobility when auto connecting to any WiFi NAT or 4G LTE internet data connection without burdening users to run a port knocker app should be used. I'm leaning toward the freepbx responsive firewall module because it's already done it's being improved on and it fits onto the piaf/ipbx with a single command, while the other way, adding rules to our iptables, would require dev and testing effort, and probably regular updates.

 

[jerrm]

So, what this means is, someone should do comparative analysis of the code in the PIAF firewall + the previously mentioned "iptables recent" voip firewall rule hacks, and this freepbx responsive firewall GPL module, and possibly some other asterisk iptables voip firewall rules.

Those links are pretty old school, not much "responsive" about them.

I'm leaning toward the freepbx responsive firewall module because it's already done it's being improved on and it fits onto the piaf/ipbx with a single command, while the other way, adding rules to our iptables, would require dev and testing effort, and probably regular updates.

That's fine. There are things I wonder why about, but overall it looks OK. Devil's in the details, I would need to see it in action.

I doubt we would change, much of it is already being done by us, and I am VERY particular about firewalls on exposed interfaces.

Most of the stuff I wonder about probably comes from it needing to be secure, yet generic and loose enough to support the world without pissing too many people off. It is labeled as RH/Centos derivative specific, which is an issue. I don't see anything that couldn't be applied to other distros, but doubt Sangoma cares about making tweaks to address other distro idiosyncrasies.

I'd still combine it with some of the block-as-much-as-you-can-first approach - geoblocking, string matching for clear traffic, block any clear text if forcing TLS, etc (and they may well do that in the full rule set). I'd need to fire up a CentOS VM to see the final ruleset.

If you have it up, please post:

iptables --line-numbers -vnL  -t filter
iptables --line-numbers -vnL  -t mangle
iptables --line-numbers -vnL  -t raw
iptables --line-numbers -vnL  -t nat
iptables --line-numbers -vnL  -t security