We currently do not use an RTP proxy in our service (so the audio does not ride our internet bandwidth).
Our biggest issue at the moment is the redundancy between two SER servers in dealing with symmetric NATs (specifically dealing with the individual SER server unique IP addresses and the far end customer's symmetric NAT).
If we were to use an RTP proxy, as a backup mechanism for dealing with NATs, would this alleviate the issue of multiple SER servers and symmetric NATs?
No, because RTP proxy would relay media only. SIP signalling would still go through one of the proxy servers and SIP messages would only make it to the user agent behind symmetric NAT if they were sent by the proxy server originally contacted by the user agent (with the same IP address).
Jan.
On 08-02 13:19, Darren Sessions wrote:
We currently do not use an RTP proxy in our service (so the audio does not ride our internet bandwidth).
Our biggest issue at the moment is the redundancy between two SER servers in dealing with symmetric NATs (specifically dealing with the individual SER server unique IP addresses and the far end customer's symmetric NAT).
If we were to use an RTP proxy, as a backup mechanism for dealing with NATs, would this alleviate the issue of multiple SER servers and symmetric NATs?
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I sent the email to the mailing list and realized the answer about 15 minutes afterwards. Your email Jan, confirms it.
I had discussed session border controllers with Jiri many months ago and was told a session border controller was not a good approach as they severely complicate signaling matters.
Other than using a session border controller, are there any viable solutions to this problem without resorting to a IP failover cluster or something of that nature?
Thanks,
- Darren
On 2/8/05 5:49 PM, "Jan Janak" jan@iptel.org wrote:
No, because RTP proxy would relay media only. SIP signalling would still go through one of the proxy servers and SIP messages would only make it to the user agent behind symmetric NAT if they were sent by the proxy server originally contacted by the user agent (with the same IP address).
Jan.
On 08-02 13:19, Darren Sessions wrote:
We currently do not use an RTP proxy in our service (so the audio does not ride our internet bandwidth).
Our biggest issue at the moment is the redundancy between two SER servers in dealing with symmetric NATs (specifically dealing with the individual SER server unique IP addresses and the far end customer's symmetric NAT).
If we were to use an RTP proxy, as a backup mechanism for dealing with NATs, would this alleviate the issue of multiple SER servers and symmetric NATs?
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Darren,
Disregarding any implementation aspects, the only complication a SBC can introduce is an additional hop in the signaling path. On the other hand, the SBC comes into focus when is about: -decoupling the NAT traversal from the routing logic - in case of a very complex service and routing logic or when is about considerations like yours; - distributed NAT traversal - keeping the media as local as possible in platforms with a wide-geographical coverage.
Best regards, Marian
Darren Sessions wrote:
I sent the email to the mailing list and realized the answer about 15 minutes afterwards. Your email Jan, confirms it.
I had discussed session border controllers with Jiri many months ago and was told a session border controller was not a good approach as they severely complicate signaling matters.
Other than using a session border controller, are there any viable solutions to this problem without resorting to a IP failover cluster or something of that nature?
Thanks,
- Darren
On 2/8/05 5:49 PM, "Jan Janak" jan@iptel.org wrote:
No, because RTP proxy would relay media only. SIP signalling would still go through one of the proxy servers and SIP messages would only make it to the user agent behind symmetric NAT if they were sent by the proxy server originally contacted by the user agent (with the same IP address).
Jan.
On 08-02 13:19, Darren Sessions wrote:
We currently do not use an RTP proxy in our service (so the audio does not ride our internet bandwidth).
Our biggest issue at the moment is the redundancy between two SER servers in dealing with symmetric NATs (specifically dealing with the individual SER server unique IP addresses and the far end customer's symmetric NAT).
If we were to use an RTP proxy, as a backup mechanism for dealing with NATs, would this alleviate the issue of multiple SER servers and symmetric NATs?
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
There is a recent discussion about SBCs on the sip forum mailing list. shortly, sbcs are a technique to harm QoS through bandwidth consumption and packet latency, and to affect reliability through introduction of a single point of failure. There are also extensibility concerns.
One can still achieve NAT traversal and failover capability without SBCs. Which is not a blank statement -- my company, iptelorg, has developed such product recently.
-jiri
At 11:41 PM 2/10/2005, Marian Dumitru wrote:
Hi Darren,
Disregarding any implementation aspects, the only complication a SBC can introduce is an additional hop in the signaling path. On the other hand, the SBC comes into focus when is about: -decoupling the NAT traversal from the routing logic - in case of a very complex service and routing logic or when is about considerations like yours; - distributed NAT traversal - keeping the media as local as possible in platforms with a wide-geographical coverage.
Best regards, Marian
Darren Sessions wrote:
I sent the email to the mailing list and realized the answer about 15 minutes afterwards. Your email Jan, confirms it. I had discussed session border controllers with Jiri many months ago and was told a session border controller was not a good approach as they severely complicate signaling matters. Other than using a session border controller, are there any viable solutions to this problem without resorting to a IP failover cluster or something of that nature? Thanks,
- Darren
On 2/8/05 5:49 PM, "Jan Janak" jan@iptel.org wrote:
No, because RTP proxy would relay media only. SIP signalling would still go through one of the proxy servers and SIP messages would only make it to the user agent behind symmetric NAT if they were sent by the proxy server originally contacted by the user agent (with the same IP address).
Jan.
On 08-02 13:19, Darren Sessions wrote:
We currently do not use an RTP proxy in our service (so the audio does not ride our internet bandwidth).
Our biggest issue at the moment is the redundancy between two SER servers in dealing with symmetric NATs (specifically dealing with the individual SER server unique IP addresses and the far end customer's symmetric NAT).
If we were to use an RTP proxy, as a backup mechanism for dealing with NATs, would this alleviate the issue of multiple SER servers and symmetric NATs?
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Voice System http://www.voice-system.ro
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
I have to admit I'm not so much involved in the theoretical discussions. But from practical point of view, I see no difference on doing the NAT traversal on the main server or remotely (via SBC) - you still have to do some media relaying, so QoS and delay will be affected in the same way.
For a worldwide spread VoIP provider, having a centralized NAT traversal will not scale, risking a bandwidth exhaustion because of media relaying. We came up with a solution based on a distributed set of NAT traversal server, configuration which will eliminate bandwidth bottle-necks and the existence of the single point of failure. Even better, you will get a better QoS since the media doesn't have to cross half of globe just for the sake of NAT traversal. We can also see this approach in Skype design and this is one of the think that contributes to its success.
Now, Jiri, don't get me wrong, but I didn't suggest to use SBCs in order to achieve High-Availability. It was just sharing with Darren some of our experience in deploying High-Availability support for SER platforms vis-a-vis of any type of NAT traversal - local or remote.
Best regards Marian
Jiri Kuthan wrote:
There is a recent discussion about SBCs on the sip forum mailing list. shortly, sbcs are a technique to harm QoS through bandwidth consumption and packet latency, and to affect reliability through introduction of a single point of failure. There are also extensibility concerns.
One can still achieve NAT traversal and failover capability without SBCs. Which is not a blank statement -- my company, iptelorg, has developed such product recently.
-jiri
At 11:41 PM 2/10/2005, Marian Dumitru wrote:
Hi Darren,
Disregarding any implementation aspects, the only complication a SBC can introduce is an additional hop in the signaling path. On the other hand, the SBC comes into focus when is about: -decoupling the NAT traversal from the routing logic - in case of a very complex service and routing logic or when is about considerations like yours; - distributed NAT traversal - keeping the media as local as possible in platforms with a wide-geographical coverage.
Best regards, Marian
Darren Sessions wrote:
I sent the email to the mailing list and realized the answer about 15 minutes afterwards. Your email Jan, confirms it. I had discussed session border controllers with Jiri many months ago and was told a session border controller was not a good approach as they severely complicate signaling matters. Other than using a session border controller, are there any viable solutions to this problem without resorting to a IP failover cluster or something of that nature? Thanks,
- Darren
On 2/8/05 5:49 PM, "Jan Janak" jan@iptel.org wrote:
No, because RTP proxy would relay media only. SIP signalling would still go through one of the proxy servers and SIP messages would only make it to the user agent behind symmetric NAT if they were sent by the proxy server originally contacted by the user agent (with the same IP address).
Jan.
On 08-02 13:19, Darren Sessions wrote:
We currently do not use an RTP proxy in our service (so the audio does not ride our internet bandwidth).
Our biggest issue at the moment is the redundancy between two SER servers in dealing with symmetric NATs (specifically dealing with the individual SER server unique IP addresses and the far end customer's symmetric NAT).
If we were to use an RTP proxy, as a backup mechanism for dealing with NATs, would this alleviate the issue of multiple SER servers and symmetric NATs?
At 12:54 AM 2/11/2005, Marian Dumitru wrote:
I have to admit I'm not so much involved in the theoretical discussions. But from practical point of view, I see no difference on doing the NAT traversal on the main server or remotely (via SBC) - you still have to do some media relaying, so QoS and delay will be affected in the same way.
For a worldwide spread VoIP provider, having a centralized NAT traversal will not scale, risking a bandwidth exhaustion because of media relaying. We came up with a solution based on a distributed set of NAT traversal server, configuration which will eliminate bandwidth bottle-necks and the existence of the single point of failure. Even better, you will get a better QoS since the media doesn't have to cross half of globe just for the sake of NAT traversal.
That's very interesting. so how do you do things such as failover during existing call and how do you do guarantee that RTT is not unnecessarily long?
We can also see this approach in Skype design and this is one of the think that contributes to its success.
I think that's a different approach -- see http://arxiv.org/pdf/cs.NI/0412017 skype attempts not to distribute but to completely offload media processing away from service provider.
-jiri
ps -- for the rest of conversation, I suggest we give up on use of the term "SBC" which has no real technical meaning.
-
Darren Sessions -
Jan Janak -
Jiri Kuthan -
Marian Dumitru