Hello,
Does anyone have experience with SIP and conntrackd? Our media and signaling is separated. Does this work for VPN connections where SIP is sent over the VPN but the media over public internet?
Thanks,
Grant
On Wednesday 30 September 2015 07:19:08 Grant Bagdasarian wrote:
Does anyone have experience with SIP and conntrackd? Our media and signaling is separated. Does this work for VPN connections where SIP is sent over the VPN but the media over public internet?
I don't see the relation with conntrackd and your setup, unless you are using some sip inspection to open the (local) rtp ports for specific source/destinations. Which is a very bad idea IMHO, my experience is that any of such ALG just cause more problems.
But if you use rtpengine and advertise the public ips in SDP the UAs will contact them, the engine will learn the correct ipadress. It is up to routing at the client to seperate the traffic correctly.
IIRC rtpproxy works the same.
Yes, I understand. Let me explain it like this and forget about VPN:
A phone call is set up from A to C through B.
A connects to B which in turn connects the call to C. All traffic is sent using UDP over the public internet. B has a firewall on both ends, so between A and B and B and C. A is connected to C in say 10 seconds and they're exchanging RTP. Now, the firewalls at B are turned off, or crash or whatever, mid call.
Would this cause the session to be disconnected? The media is obviously gone, but will the session remain active? I'm looking for a way to restore almost instantly in case of any failure, be it firewall related.
My idea was to configure conntrackd on the firewalls which are setup in HA mode and where a crash of the primary would result in a failover to the backup with full connection restore.
-----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Daniel Tryba Sent: Wednesday, September 30, 2015 10:56 AM To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] SIP and conntrackd experience?
On Wednesday 30 September 2015 07:19:08 Grant Bagdasarian wrote:
Does anyone have experience with SIP and conntrackd? Our media and signaling is separated. Does this work for VPN connections where SIP is sent over the VPN but the media over public internet?
I don't see the relation with conntrackd and your setup, unless you are using some sip inspection to open the (local) rtp ports for specific source/destinations. Which is a very bad idea IMHO, my experience is that any of such ALG just cause more problems.
But if you use rtpengine and advertise the public ips in SDP the UAs will contact them, the engine will learn the correct ipadress. It is up to routing at the client to seperate the traffic correctly.
IIRC rtpproxy works the same.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Wednesday 30 September 2015 13:07:12 Grant Bagdasarian wrote:
A is connected to C in say 10 seconds and they're exchanging RTP. Now, the firewalls at B are turned off, or crash or whatever, mid call.
Would this cause the session to be disconnected? The media is obviously gone, but will the session remain active? I'm looking for a way to restore almost instantly in case of any failure, be it firewall related.
My idea was to configure conntrackd on the firewalls which are setup in HA mode and where a crash of the primary would result in a failover to the backup with full connection restore.
As long as there is no additional signalling (DTMF over SIP INFO, session timers, onhold events....) or endpoints detect the lack of RTP (or RTCP) after a short timeout, the SIP session is still alive according to the endpoints.
So if RTP is only forwarded by the kernel (like the kernel forwarding capabilities of rtpengine) and you could replicate these forwards to a standby server, you could do a failover of both SIP and RTP. Theoretically...
If you are running rtpproxy, which actively accepts and forwards the RTP traffic, you'd have to replicate the state of the proxy to a standby machine. Which is AFAIK not possible.
Alright, I understand. Thanks for explaining.
How do big carriers handle these kinds of scenarios where a sudden outage in a key component would cause calls to be dropped? Is this the achilles heel of voice? Is there special kind of software or hardware (or both) for handling these kinds of scenarios?
-----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Daniel Tryba Sent: Wednesday, September 30, 2015 4:19 PM To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] SIP and conntrackd experience?
On Wednesday 30 September 2015 13:07:12 Grant Bagdasarian wrote:
A is connected to C in say 10 seconds and they're exchanging RTP. Now, the firewalls at B are turned off, or crash or whatever, mid call.
Would this cause the session to be disconnected? The media is obviously gone, but will the session remain active? I'm looking for a way to restore almost instantly in case of any failure, be it firewall related.
My idea was to configure conntrackd on the firewalls which are setup in HA mode and where a crash of the primary would result in a failover to the backup with full connection restore.
As long as there is no additional signalling (DTMF over SIP INFO, session timers, onhold events....) or endpoints detect the lack of RTP (or RTCP) after a short timeout, the SIP session is still alive according to the endpoints.
So if RTP is only forwarded by the kernel (like the kernel forwarding capabilities of rtpengine) and you could replicate these forwards to a standby server, you could do a failover of both SIP and RTP. Theoretically...
If you are running rtpproxy, which actively accepts and forwards the RTP traffic, you'd have to replicate the state of the proxy to a standby machine. Which is AFAIK not possible.
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Thursday 01 October 2015 07:35:06 Grant Bagdasarian wrote:
How do big carriers handle these kinds of scenarios where a sudden outage in a key component would cause calls to be dropped? Is this the achilles heel of voice? Is there special kind of software or hardware (or both) for handling these kinds of scenarios?
See http://www.ng-voice.com/redundancy-maxx/ for example.
Your specific concern: "Both our deployed SEMS (thanks to the Frafos Team) and our deployed RTPEngine (thanks to Carlos) use a Redis-Database for storing information on the current calls, however in both cases through a proprietary extension. The Redis- database is distributed among the two servers, so if we start the services on the passive node, all sessions can continue without service interuption."
-
Daniel Tryba -
Grant Bagdasarian