Equivalent to Asterisk's "directrtpsetup=yes"?
Hello Thanks to "directrtpsetup=yes", it appears that Asterisk can act as an SIP proxy and a PBX at the same time, ie. RTP packets will flow directly between the two SIP end-points with Asterisk still being able to provide PBX services like call transfer, MoH, etc. The point is to lower latency for packets to reach their final destination and lower CPU load on the Freeswitch server. Does Freeswitch offer the same feature, or must RTP packets always go through the Freeswitch servers? Thank you. -- View this message in context: http://old.nabble.com/Equivalent-to-Asterisk%27s-%22directrtpsetup%3Dyes%22-... Sent from the Freeswitch-users mailing list archive at Nabble.com.
Fred-145 was wondering:
Does Freeswitch offer the same feature, or must RTP packets always go through the Freeswitch servers?
http://wiki.freeswitch.org/wiki/Bypass_Media
Thank you.
You're welcome. -- Russell Mosemann
On Wed, 27 Jan 2010 06:47:28 -0600, "Russell Mosemann" <Russell.Mosemann@cune.org> wrote:
Thanks everyone. I'll experiment with Freeswitch in the LAN behind a NAT router and check if performance is good enough to avoid using the bypass-media option.
Hi Fred, Check out bypass_media mode: http://wiki.freeswitch.org/wiki/Bypass_Media Cheers, Rob On Jan 27, 2010, at 6:38 AM, Fred-145 wrote:
Hello
Thanks to "directrtpsetup=yes", it appears that Asterisk can act as an SIP proxy and a PBX at the same time, ie. RTP packets will flow directly between the two SIP end-points with Asterisk still being able to provide PBX services like call transfer, MoH, etc. The point is lower latency for packets to reach their final destination and lower CPU load on the Freeswitch server.
Does Freeswitch offer the same feature, or must RTP packets always go through the Freeswitch servers?
Thank you. -- View this message in context: http://old.nabble.com/Equivalent-to-Asterisk%27s-%22directrtpsetup%3Dyes%22-... Sent from the Freeswitch-users mailing list archive at Nabble.com.
_______________________________________________ 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
set bypass_media=true On Wednesday 27 January 2010, Fred-145 wrote:
Hello
Thanks to "directrtpsetup=yes", it appears that Asterisk can act as an SIP proxy and a PBX at the same time, ie. RTP packets will flow directly between the two SIP end-points with Asterisk still being able to provide PBX services like call transfer, MoH, etc. The point is lower latency for packets to reach their final destination and lower CPU load on the Freeswitch server.
Does Freeswitch offer the same feature, or must RTP packets always go through the Freeswitch servers?
Thank you.
On Wed, 27 Jan 2010 07:50:16 -0500, Sergey Okhapkin <sos@sokhapkin.dyndns.org> wrote:
set bypass_media=true
Thanks everyone for the feedback. Are there drawbacks to having RTP pakets flow directly between the SIP end-points?
On Fri, 29 Jan 2010 08:26:53 -0600, Brian West <brian@freeswitch.org> wrote:
Are there drawbacks to having RTP pakets flow directly between the SIP end-points?
Well if nat is involved you might have issues.
Since Freeswitch has handled the initial connection and the NAT box has opened the range of UDP ports for RTP/RTCP, in what case would the two end-points have a problem with NAT? Is it possible for end-points to send IP/port information in the midst of a conversation?
Fred-145 <codecomplete@free.fr> said:
Since Freeswitch has handled the initial connection and the NAT box has opened the range of UDP ports for RTP/RTCP, in what case would the two end-points have a problem with NAT?
The ports are open between the endpoint and Freeswitch. The ports are not open between the two endpoints themselves. If each endpoint is behind its own NAT, neither endpoint will be able to contact the other endpoint unless some kind of forwarding is set up on the firewall to map the external IP address and port to an internal IP address and port. -- Russell Mosemann ________________________________________________________ Concordia University, Nebraska See http://www.cune.edu/ for the latest news and events!
On Fri, 29 Jan 2010 16:43:59 -0000, <Russell.Mosemann@cune.org> wrote:
The ports are open between the endpoint and Freeswitch. The ports are not open between the two endpoints themselves. If each endpoint is behind its own NAT, neither endpoint will be able to contact the other endpoint unless some kind of forwarding is set up on the firewall to map the external IP address and port to an internal IP address and port.
Thanks but the context I was refering to is... 1. Freeswitch is configured in BypassMedia mode 2. The firewall and the local end-points are configured so that a series of UDP ranges are mapped to their respective end-point (eg. UDP100-1003 for extension #1, 1004-1007 for #2, etc.) ... so that RTP packets flow directly between the two end-points Brian says above that there might be cases where NAT could be a problem. When could this happen? I'd like to get to the bottom of this so that in case a server is a bit short on CPU/network power, I know that there's the alternative of RTP packets by-passing the server... but I also need to know what issues this setup can cause. Thank you.
If FreeSWITCH is configured in bypass-media mode, and the endpoint behing NAT cannot use any of the NAT avoiding techiques to send public IP in the SDP (STUN etc.) then you'll have issues. You can do what do I do, which is to make different sofia profiles for NATed and non-NATED endpoints (FS has many server-side nat traversal mechanisms). Regards, Ognjen On Sat, Jan 30, 2010 at 2:53 PM, Fred-145 <codecomplete@free.fr> wrote:
On Fri, 29 Jan 2010 16:43:59 -0000, <Russell.Mosemann@cune.org> wrote:
The ports are open between the endpoint and Freeswitch. The ports are not open between the two endpoints themselves. If each endpoint is behind its own NAT, neither endpoint will be able to contact the other endpoint unless some kind of forwarding is set up on the firewall to map the external IP address and port to an internal IP address and port.
Thanks but the context I was refering to is... 1. Freeswitch is configured in BypassMedia mode 2. The firewall and the local end-points are configured so that a series of UDP ranges are mapped to their respective end-point (eg. UDP100-1003 for extension #1, 1004-1007 for #2, etc.) ... so that RTP packets flow directly between the two end-points
Brian says above that there might be cases where NAT could be a problem. When could this happen?
I'd like to get to the bottom of this so that in case a server is a bit short on CPU/network power, I know that there's the alternative of RTP packets by-passing the server... but I also need to know what issues this setup can cause.
Thank you.
_______________________________________________ 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
On Sun, 31 Jan 2010 11:47:42 +0100, Ognjen Seslija <oseslija@gmail.com> wrote:
If FreeSWITCH is configured in bypass-media mode, and the endpoint behing NAT cannot use any of the NAT avoiding techiques to send public IP in the SDP (STUN etc.) then you'll have issues.
In this scenario, Freeswitch and the SIP end-points are configured to handle NAT. I'm just curious to know what issues/drawbacks I should expect if I decide to lower the CPU/network load on the Freeswitch server if I decide to configure it in bypass-media mode. Are there features that aren't available when the two end-points speak RTP directly instead of having RTP packets go through Freeswitch?
You can do what do I do, which is to make different sofia profiles for NATed and non-NATED endpoints (FS has many server-side nat traversal mechanisms).
If you have time, I'm interested in knowing more about your setup.
Fred-145 asked:
Are there features that aren't available when the two end-points speak RTP directly instead of having RTP packets go through Freeswitch?
I wasn't paying close attention, but in a recent discussion, someone wanted to have moh in a bypass-media situation. I think there was a way to do that, but then there was an issue with going back to bypass-media after the call was taken off hold. If you look through the list archive, you should be able to find it. -- Russell Mosemann
Going back no_media after hold isn't supported yet.. Anthony said he would add it if someone really really wanted it and posted a bounty of $500 to cover his time to implement it. /b On Jan 31, 2010, at 4:35 PM, Russell Mosemann wrote:
I wasn't paying close attention, but in a recent discussion, someone wanted to have moh in a bypass-media situation. I think there was a way to do that, but then there was an issue with going back to bypass-media after the call was taken off hold. If you look through the list archive, you should be able to find it.
On Sun, 31 Jan 2010 22:36:25 -0600, Brian West <brian@freeswitch.org> wrote:
Going back no_media after hold isn't supported yet.. Anthony said he would add it if someone really really wanted it and posted a bounty of $500 to cover his time to implement it.
Thanks all for the info. The bottom line seems to be that it's really not a good idea to remove Freeswitch from the media path, and it's a better idea to look elsewhere if scalability is an issue.
Fred-145 <codecomplete@free.fr> wrote:
On Sun, 31 Jan 2010 22:36:25 -0600, Brian West <brian@freeswitch.org> wrote:
Going back no_media after hold isn't supported yet.. Anthony said he would add it if someone really really wanted it and posted a bounty of $500 to cover his time to implement it.
Thanks all for the info. The bottom line seems to be that it's really not a good idea to remove Freeswitch from the media path, and it's a better idea to look elsewhere if scalability is an issue.
I don't think that's a good summary. What contributors to this thread are saying is that there are trade-offs: you can keep FreeSWITCH in the media path, with its consequent load on the server, or you can configure it for bypass media or proxy media modes to reduce the load. In the latter case, nat traversal issues may have to be dealt with, if relevant to your situation, and if anyone wants to return to bypass media after hold, they're welcome to pay the bounty to have this functionality implemented.
I'd say, you need bypass_media if provide SIP wholesale kind of service, and stay in audio path if you provide PBX-like kind of service. On Monday 01 February 2010, Fred-145 wrote:
On Sun, 31 Jan 2010 22:36:25 -0600, Brian West
<brian@freeswitch.org> wrote:
Going back no_media after hold isn't supported yet.. Anthony said he would add it if someone really really wanted it and posted a bounty of $500 to cover his time to implement it.
Thanks all for the info. The bottom line seems to be that it's really not a good idea to remove Freeswitch from the media path, and it's a better idea to look elsewhere if scalability is an issue.
_______________________________________________ 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
On Mon, 1 Feb 2010 06:58:21 -0500, Sergey Okhapkin <sos@sokhapkin.dyndns.org> wrote:
I'd say, you need bypass_media if provide SIP wholesale kind of service, and stay in audio path if you provide PBX-like kind of service.
Yup, that's a better summary. Thanks all for the information. Things make a lot more sense now :-)
On Wed, Jan 27, 2010 at 7:38 AM, Fred-145 <codecomplete@free.fr> wrote:
Hello
Thanks to "directrtpsetup=yes", it appears that Asterisk can act as an SIP proxy and a PBX at the same time, ie. RTP packets will flow directly between the two SIP end-points with Asterisk still being able to provide PBX services like call transfer, MoH, etc. The point is to lower latency for packets to reach their final destination and lower CPU load on the Freeswitch server.
Does Freeswitch offer the same feature, or must RTP packets always go through the Freeswitch servers?
This isn't exactly true... If you do some research you'll find that OEJ (the author of the Asterisk SIP channel driver) does NOT recommend the use of directrtpsetup because its use hasn't been tested with many scenarios (including some you describe, I'm sure). AFAIK it's still marked "experimental". The last time this came up on Asterisk-users here was the exchange: Kevin P. Fleming wrote:
Kristian Kielhofner wrote:
What version of Asterisk is this? Last I heard (from Olle) this option was very experimental and should not be used on production systems.
He even helpfully documented it that way in the sip.conf.sample file, along with a list of (known) cases where it will fail, although there are probably plenty more.
So Kevin Fleming agrees. Needless to say FreeSWITCH has bypass_media. Last I heard FreeSWITCH will re-INVITE itself back in the media path if you put a call on hold (for example) but it won't go back to bypass_media when you take the call off hold. Anthony said it would probably take about $500 in bounty to get that functionality. Then again, maybe he just decided to do anyway it because he thought it was cool. That's been known to happen too. -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com
participants (9)
-
Brian West
-
Fred-145
-
Jason White
-
Kristian Kielhofner
-
Ognjen Seslija
-
Rob Forman
-
Russell Mosemann
-
Russell.Mosemann＠cune.org
-
Sergey Okhapkin