I am trying to find the best solution to generate ring on 180 but bypass on 183. We are in the middle, customer -> FS -> pstn. We bypass_media=true for all calls. However, sometimes we get a 180 from the PSTN and FS relays that to the customer, but the customer is not generating ring so the calling party hears dead air. So, the solution would be to anchor media and generate ring when we get a 180, but once the 183 or 200 hits, bypass starts. I suppose we could do an expression match on the 180, ignore early media, generate ring, and bypass media after bridge. Just wondering if there was a better alternative solution.
David, While the solution you've proposed below is the best in terms of media handling I'm not sure how well it will work in practice. If you intercept the 180 and provide 183 w/ media the calling endpoint will get media (ringback) from the IP address of your FS machine (no problem). However, when the 183/200 w/ media comes from the remote end it is going to contain a different IP address and port if you (somehow) re-enable bypass_media. Even if FreeSWITCH could be coerced into doing this I'm not sure that all endpoints will react well to this change in connection information from your 183 to the remote 183/200. Technically speaking (RFC) there's nothing wrong with it but we all know that doesn't mean there won't be issues doing this with the various endpoints in the field. You /may/ get stuck anchoring the media for the entire call in these cases where your upstream returns a 180. Other than that I'd be interested to see how you get along with this... On Wed, Jun 15, 2011 at 12:24 AM, David Aldworth <daldworth@teliax.com> wrote:
I am trying to find the best solution to generate ring on 180 but bypass on 183. We are in the middle, customer -> FS -> pstn. We bypass_media=true for all calls. However, sometimes we get a 180 from the PSTN and FS relays that to the customer, but the customer is not generating ring so the calling party hears dead air. So, the solution would be to anchor media and generate ring when we get a 180, but once the 183 or 200 hits, bypass starts. I suppose we could do an expression match on the 180, ignore early media, generate ring, and bypass media after bridge. Just wondering if there was a better alternative solution. _______________________________________________ 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
-- Kristian Kielhofner
Your comments about different endpoints reacting different is my concern exactly. That said, we came up with a fairly simple solution (below) that, thus far, seems alright. However, not all scenarios have been fully test, such as what happens if we get an early media operator intercept with the 183, what happens if the endpoint rejects the re-invite, etc. <action application="set" data="bypass_media=false"/> <action application="set" data="ringback=$${us-ring}"/> <action application="set" data="bypass_media_after_bridge=true"/> On Jun 15, 2011, at 4:06 PM, Kristian Kielhofner wrote:
David,
While the solution you've proposed below is the best in terms of media handling I'm not sure how well it will work in practice.
If you intercept the 180 and provide 183 w/ media the calling endpoint will get media (ringback) from the IP address of your FS machine (no problem). However, when the 183/200 w/ media comes from the remote end it is going to contain a different IP address and port if you (somehow) re-enable bypass_media. Even if FreeSWITCH could be coerced into doing this I'm not sure that all endpoints will react well to this change in connection information from your 183 to the remote 183/200. Technically speaking (RFC) there's nothing wrong with it but we all know that doesn't mean there won't be issues doing this with the various endpoints in the field.
You /may/ get stuck anchoring the media for the entire call in these cases where your upstream returns a 180. Other than that I'd be interested to see how you get along with this...
On Wed, Jun 15, 2011 at 12:24 AM, David Aldworth <daldworth@teliax.com> wrote:
I am trying to find the best solution to generate ring on 180 but bypass on 183. We are in the middle, customer -> FS -> pstn. We bypass_media=true for all calls. However, sometimes we get a 180 from the PSTN and FS relays that to the customer, but the customer is not generating ring so the calling party hears dead air. So, the solution would be to anchor media and generate ring when we get a 180, but once the 183 or 200 hits, bypass starts. I suppose we could do an expression match on the 180, ignore early media, generate ring, and bypass media after bridge. Just wondering if there was a better alternative solution. _______________________________________________ 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
-- Kristian Kielhofner
_______________________________________________ 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
David, I was going to suggest bypass_media_after_bridge (re-INVITE) but I've never used it so I wasn't sure how well it worked. This is still a very interesting situation... One question: How do you detect the remote end has responded with a 180/183 w/o SDP in order to execute these commands conditionally? On Wed, Jun 15, 2011 at 6:35 PM, David Aldworth <daldworth@teliax.com> wrote:
Your comments about different endpoints reacting different is my concern exactly. That said, we came up with a fairly simple solution (below) that, thus far, seems alright. However, not all scenarios have been fully test, such as what happens if we get an early media operator intercept with the 183, what happens if the endpoint rejects the re-invite, etc.
<action application="set" data="bypass_media=false"/> <action application="set" data="ringback=$${us-ring}"/> <action application="set" data="bypass_media_after_bridge=true"/>
-- Kristian Kielhofner
According to the wiki both execute_on_media and execute_on_preanswer don't distinguish between the various 180/183 with or without SDP scenarios. I guess I just may have to try it :). On Thu, Jun 16, 2011 at 1:23 PM, Brian West <brian@freeswitch.org> wrote:
You could use execute_on_media to set a variable ;)
/b
-- Kristian Kielhofner
if you set ringback variable on A and bypass_media_after_bridge=true and don't set ignore_early_media you should get what you want. The generate will only happen on 180 and the 183 would bridge. and in both cases once it's answered it goes to no media mode. On Thu, Jun 16, 2011 at 12:28 PM, Kristian Kielhofner <kris@kriskinc.com> wrote:
According to the wiki both execute_on_media and execute_on_preanswer don't distinguish between the various 180/183 with or without SDP scenarios.
I guess I just may have to try it :).
On Thu, Jun 16, 2011 at 1:23 PM, Brian West <brian@freeswitch.org> wrote:
You could use execute_on_media to set a variable ;)
/b
-- Kristian Kielhofner
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Thank you. That is indeed the scenario I was trying to confirm. So far I've had no problem with the dp settings of anchoring, then setting US ring, then bypassing after bridge. Thanks to Math for help in the forum too! He suggested I add the US ring and that without it FS would just relay the 180. The execute_on_media/preanswer has interesting implications too... David On Jun 16, 2011, at 11:37 AM, Anthony Minessale wrote:
if you set ringback variable on A and bypass_media_after_bridge=true and don't set ignore_early_media you should get what you want. The generate will only happen on 180 and the 183 would bridge.
and in both cases once it's answered it goes to no media mode.
On Thu, Jun 16, 2011 at 12:28 PM, Kristian Kielhofner <kris@kriskinc.com> wrote:
According to the wiki both execute_on_media and execute_on_preanswer don't distinguish between the various 180/183 with or without SDP scenarios.
I guess I just may have to try it :).
On Thu, Jun 16, 2011 at 1:23 PM, Brian West <brian@freeswitch.org> wrote:
You could use execute_on_media to set a variable ;)
/b
-- Kristian Kielhofner
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ 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
Hrm.. that is true you can get a 180 with an SDP which we treat like a 183 but hrm I think you're correct. /b On Jun 16, 2011, at 12:28 PM, Kristian Kielhofner wrote:
According to the wiki both execute_on_media and execute_on_preanswer don't distinguish between the various 180/183 with or without SDP scenarios.
I guess I just may have to try it :).
On Thu, Jun 16, 2011 at 1:23 PM, Brian West <brian@freeswitch.org> wrote:
You could use execute_on_media to set a variable ;)
/b
participants (4)
-
Anthony Minessale
-
Brian West
-
David Aldworth
-
Kristian Kielhofner