Hello, We would like to hear early media without CHANNEL_BRIDGE event These are failed calls and callers would like to hear the message that the provider plays Because the caller thinks the call is answered if originate returns. as far as I understand: -early media makes the originate return -if we ignore early media the bridge won't return, but we don't hear it we would like both of them, is it possible somehow? I 'm not sure I fully understand all of the ignore_early_media options but I haven't find solution for this, Could you please advise me one, if there is any? I'm thinking about we maybe need a new ignore_early_media option like "consume" but sending the media to the caller instead of dropping it If there isn't already a solution I also would appreciate if you let me know your opinion about this idea Thanks advance, Tamas
What constitutes a failure? What I mean by that is, are *all* calls that have early media a "failed" call? Or just certain calls? What about ringing in early media? You could use monitor_early_media_fail and attempt to analyze the progress tones, i.e. if you hear ringing then it's a good call but otherwise it's a "failure." However, I'm not aware of any way to have the early media flow to the calling party with having the bridge/originate be "successful." The only way to know for sure is to check for a hangup cause. Could you explain more about what you are trying to accomplish? Perhaps there is another way of dealing with the early media conundrum. -MC On Thu, Jan 10, 2013 at 3:24 AM, Tamas.Cseke <cstomi.levlist@gmail.com>wrote:
Hello,
We would like to hear early media without CHANNEL_BRIDGE event These are failed calls and callers would like to hear the message that the provider plays Because the caller thinks the call is answered if originate returns.
as far as I understand: -early media makes the originate return -if we ignore early media the bridge won't return, but we don't hear it
we would like both of them, is it possible somehow?
I 'm not sure I fully understand all of the ignore_early_media options but I haven't find solution for this, Could you please advise me one, if there is any?
I'm thinking about we maybe need a new ignore_early_media option like "consume" but sending the media to the caller instead of dropping it If there isn't already a solution I also would appreciate if you let me know your opinion about this idea
Thanks advance, Tamas
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
I think I understand Tamas as I have similar question. I think the CHANNEL_BRIDGE event fires when you get media from the b-leg, and 2 CHANNEL_ANSWER event fired on both channels when the b-leg answered. ignore_early_media on this case can prevent CHANNEL_BRIDGE from fire until the b-leg really answers the call. however, In some cased we'd like the a leg hear the early media, but get the CHANNEL_BRIDGE when b-leg is really answer the call. I thought it maybe impossible for now for the a leg to hear early media on a unbridged channel. Or maybe there's an option enable this I can't remember. FS considers a call/bridge is "success" when get early media, e.g. bridge user/b1|user/b2 when user/b1 sends early media it never has a chance to call user/b2. If user/b plays "the line is busy, please call later …. ", and the a leg can hear that will be helpful, and for a patient a-leg, it will eventually can b2 when b1 timeout. the bridge user/b1,user/b2 case may be a little harder, what if both sends back early media, do we choose one to pass to the a leg, or mix them? or make a option to select it? so I think Tamas' question is - is it possible to work exactly as the same as the ignore_early_media scenario, but let the a leg hear early media. Thanks. -- Seven Du Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, January 11, 2013 at 1:45 AM, Michael Collins wrote:
What constitutes a failure? What I mean by that is, are *all* calls that have early media a "failed" call? Or just certain calls? What about ringing in early media?
You could use monitor_early_media_fail and attempt to analyze the progress tones, i.e. if you hear ringing then it's a good call but otherwise it's a "failure." However, I'm not aware of any way to have the early media flow to the calling party with having the bridge/originate be "successful." The only way to know for sure is to check for a hangup cause.
Could you explain more about what you are trying to accomplish? Perhaps there is another way of dealing with the early media conundrum.
-MC
On Thu, Jan 10, 2013 at 3:24 AM, Tamas.Cseke <cstomi.levlist@gmail.com (mailto:cstomi.levlist@gmail.com)> wrote:
Hello,
We would like to hear early media without CHANNEL_BRIDGE event These are failed calls and callers would like to hear the message that the provider plays Because the caller thinks the call is answered if originate returns.
as far as I understand: -early media makes the originate return -if we ignore early media the bridge won't return, but we don't hear it
we would like both of them, is it possible somehow?
I 'm not sure I fully understand all of the ignore_early_media options but I haven't find solution for this, Could you please advise me one, if there is any?
I'm thinking about we maybe need a new ignore_early_media option like "consume" but sending the media to the caller instead of dropping it If there isn't already a solution I also would appreciate if you let me know your opinion about this idea
Thanks advance, Tamas
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (mailto:consulting@freeswitch.org) http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org (mailto: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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org (mailto:consulting@freeswitch.org) http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org (mailto: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
Hello, Yes, this was my problem and I found the solution bridge_early_media=true was what I needed http://wiki.freeswitch.org/wiki/Variable_bridge_early_media There are so many awsome early media option, I couldn't find it I hope it help you too! Thank you guys! Tamas On Fri, Jan 11, 2013 at 1:24 AM, Seven Du <dujinfang@gmail.com> wrote:
I think I understand Tamas as I have similar question.
I think the CHANNEL_BRIDGE event fires when you get media from the b-leg, and 2 CHANNEL_ANSWER event fired on both channels when the b-leg answered.
ignore_early_media on this case can prevent CHANNEL_BRIDGE from fire until the b-leg really answers the call.
however, In some cased we'd like the a leg hear the early media, but get the CHANNEL_BRIDGE when b-leg is really answer the call.
I thought it maybe impossible for now for the a leg to hear early media on a unbridged channel. Or maybe there's an option enable this I can't remember.
FS considers a call/bridge is "success" when get early media, e.g.
bridge user/b1|user/b2 when user/b1 sends early media it never has a chance to call user/b2. If user/b plays "the line is busy, please call later …. ", and the a leg can hear that will be helpful, and for a patient a-leg, it will eventually can b2 when b1 timeout.
the bridge user/b1,user/b2 case may be a little harder, what if both sends back early media, do we choose one to pass to the a leg, or mix them? or make a option to select it?
so I think Tamas' question is - is it possible to work exactly as the same as the ignore_early_media scenario, but let the a leg hear early media.
Thanks.
-- Seven Du Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
On Friday, January 11, 2013 at 1:45 AM, Michael Collins wrote:
What constitutes a failure? What I mean by that is, are *all* calls that have early media a "failed" call? Or just certain calls? What about ringing in early media?
You could use monitor_early_media_fail and attempt to analyze the progress tones, i.e. if you hear ringing then it's a good call but otherwise it's a "failure." However, I'm not aware of any way to have the early media flow to the calling party with having the bridge/originate be "successful." The only way to know for sure is to check for a hangup cause.
Could you explain more about what you are trying to accomplish? Perhaps there is another way of dealing with the early media conundrum.
-MC
On Thu, Jan 10, 2013 at 3:24 AM, Tamas.Cseke <cstomi.levlist@gmail.com>wrote:
Hello,
We would like to hear early media without CHANNEL_BRIDGE event These are failed calls and callers would like to hear the message that the provider plays Because the caller thinks the call is answered if originate returns.
as far as I understand: -early media makes the originate return -if we ignore early media the bridge won't return, but we don't hear it
we would like both of them, is it possible somehow?
I 'm not sure I fully understand all of the ignore_early_media options but I haven't find solution for this, Could you please advise me one, if there is any?
I'm thinking about we maybe need a new ignore_early_media option like "consume" but sending the media to the caller instead of dropping it If there isn't already a solution I also would appreciate if you let me know your opinion about this idea
Thanks advance, Tamas
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.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
participants (4)
-
Michael Collins
-
Seven Du
-
Tamas Cseke
-
Tamas.Cseke