Hi there, I am attempting to do a simple bridge. Leg A is an inbound DID. Leg B is terminated through a SIP carrier. I am unable to use loopback AND bypass_media_after_bridge=true. The bridge fails. Here is my three line application: Session.Answer(); Session.Execute("set", "bypass_media_after_bridge=true"); Session.Execute("bridge", "loopback/6095553828/default"); FreeSWITCH log: http://pastebin.freeswitch.org/9949 I believe the bridge fails as the SIP-REINVITE is issued and fails. Using loopback and bypass_media_after_bridge=false works fine. As does using bypass_media_after_bridge=true and sending call directly through the gateway to which the loopback points. e.g. http://pastebin.freeswitch.org/9948 Has anyone else encountered this? Am I missing something? Any help would be much appreciated! Thanks Phillip Jones
It occurred to me that I better check that this still occurs using lua and that this is not a mod_manged issue. The lua script: session:answer(); session:execute("set", "bypass_media_after_bridge=true"); session:execute("bridge", "loopback/6095553828/default"); does produce the same issue. The bridge fails. I am wondering whether this is something I should just put straight into jira. On Mon, Aug 10, 2009 at 4:35 PM, Phillip Jones<pjintheusa@gmail.com> wrote:
Hi there,
I am attempting to do a simple bridge. Leg A is an inbound DID. Leg B is terminated through a SIP carrier.
I am unable to use loopback AND bypass_media_after_bridge=true. The bridge fails.
Here is my three line application:
Session.Answer();
Session.Execute("set", "bypass_media_after_bridge=true");
Session.Execute("bridge", "loopback/6095553828/default");
FreeSWITCH log: http://pastebin.freeswitch.org/9949
I believe the bridge fails as the SIP-REINVITE is issued and fails.
Using loopback and bypass_media_after_bridge=false works fine. As does using bypass_media_after_bridge=true and sending call directly through the gateway to which the loopback points.
e.g. http://pastebin.freeswitch.org/9948
Has anyone else encountered this? Am I missing something?
Any help would be much appreciated!
Thanks
Phillip Jones
loopback requires media you can't be using it in this manner. There is NO reason to use loopback in the first place. Can you show me what you're doing in the dialplan that requires you to use loopback? We gave you the rope... now you just have to stop from hanging yourself! :P /b On Aug 11, 2009, at 8:59 AM, Phillip Jones wrote:
It occurred to me that I better check that this still occurs using lua and that this is not a mod_manged issue.
The lua script:
session:answer(); session:execute("set", "bypass_media_after_bridge=true"); session:execute("bridge", "loopback/6095553828/default");
does produce the same issue. The bridge fails.
I am wondering whether this is something I should just put straight into jira.
Thanks for the reply Brian. I went through this fairly carefully with Mike Jerris - please see http://www.nabble.com/Calling-Multiple-Destinations-with-Failover-td24877157... I am very open to any other mechanism that allows the calling multiple destinations with carrier failover support. I would have thought this is a fairly common requirement and is a fundamental requirement in my application. As always - your help is appreciated. On Tue, Aug 11, 2009 at 10:07 AM, Brian West<brian@freeswitch.org> wrote:
loopback requires media you can't be using it in this manner. There is NO reason to use loopback in the first place. Can you show me what you're doing in the dialplan that requires you to use loopback?
We gave you the rope... now you just have to stop from hanging yourself! :P
/b
On Aug 11, 2009, at 8:59 AM, Phillip Jones wrote:
It occurred to me that I better check that this still occurs using lua and that this is not a mod_manged issue.
The lua script:
session:answer(); session:execute("set", "bypass_media_after_bridge=true"); session:execute("bridge", "loopback/6095553828/default");
does produce the same issue. The bridge fails.
I am wondering whether this is something I should just put straight into jira.
_______________________________________________ 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
This can all be accomplished with standard bridge lines stacked one on top of the other with continue_on_fail set to the list of codes you wish to fail over with. You would also want to set hangup_after_bridge=true. Loopback should NEVER be used in this case. http://wiki.freeswitch.org/wiki/Channel_Variables#continue_on_fail http://wiki.freeswitch.org/wiki/Channel_Variables#hangup_after_bridge /b On Aug 11, 2009, at 9:46 AM, Phillip Jones wrote:
Thanks for the reply Brian.
I went through this fairly carefully with Mike Jerris - please see http://www.nabble.com/Calling-Multiple-Destinations-with-Failover-td24877157...
I am very open to any other mechanism that allows the calling multiple destinations with carrier failover support. I would have thought this is a fairly common requirement and is a fundamental requirement in my application.
As always - your help is appreciated.
Can you use this method to make simultaneous calls though while preserving carrier order? i.e. each call must try carrier 1 first then carrier 2 (because each carrier terminates a different subset of numbers) So - if I did NOT want to support failover I would use: session:execute("bridge", "sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"); << call 6095553828 and 7325553828 at the same time If I were to use failover and not need multiple destinations then I would use: session:execute("bridge", "sofia/gateway/broadvox/6095553828|sofia/gateway/quest/6095553828"); << call using broadvox first and quest it that fails I need to combine: Call 6095553828 and 7325553828 simultaneously and each trying broadvox then on fail quest. session:execute("bridge", "(sofia/gateway/broadvox/6095553828|sofia/gateway/quest/6095553828),(sofia/gateway/broadvox/7325553828,sofia/gateway/quest/7325553828)"); But of course that syntax does not work. I can not see another syntax that would achieve this? On Tue, Aug 11, 2009 at 10:58 AM, Brian West<brian@freeswitch.org> wrote:
This can all be accomplished with standard bridge lines stacked one on top of the other with continue_on_fail set to the list of codes you wish to fail over with. You would also want to set hangup_after_bridge=true. Loopback should NEVER be used in this case. http://wiki.freeswitch.org/wiki/Channel_Variables#continue_on_fail http://wiki.freeswitch.org/wiki/Channel_Variables#hangup_after_bridge /b On Aug 11, 2009, at 9:46 AM, Phillip Jones wrote:
Thanks for the reply Brian.
I went through this fairly carefully with Mike Jerris - please see http://www.nabble.com/Calling-Multiple-Destinations-with-Failover-td24877157...
I am very open to any other mechanism that allows the calling multiple destinations with carrier failover support. I would have thought this is a fairly common requirement and is a fundamental requirement in my application.
As always - your help is appreciated.
_______________________________________________ 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 Tue, Aug 11, 2009 at 11:08 AM, Phillip Jones <pjintheusa@gmail.com>wrote:
Can you use this method to make simultaneous calls though while preserving carrier order? i.e. each call must try carrier 1 first then carrier 2 (because each carrier terminates a different subset of numbers)
So - if I did NOT want to support failover I would use:
session:execute("bridge", "sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"); << call 6095553828 and 7325553828 at the same time
If I were to use failover and not need multiple destinations then I would use:
session:execute("bridge", "sofia/gateway/broadvox/6095553828|sofia/gateway/quest/6095553828"); << call using broadvox first and quest it that fails
I need to combine:
Call 6095553828 and 7325553828 simultaneously and each trying broadvox then on fail quest.
session:execute("bridge",
"(sofia/gateway/broadvox/6095553828|sofia/gateway/quest/6095553828),(sofia/gateway/broadvox/7325553828,sofia/gateway/quest/7325553828)");
But of course that syntax does not work.
I can not see another syntax that would achieve this?
Just to make sure I'm reading you correctly I want to clarify... You are trying to maintain carrier order and also trying to dial simultaneously. If I understand what you mean, you have two separate dialstrings that you want to dial simultaneously and if BOTH fail, THEN you want to dial the third dialstring? If the above is correct then this dialplan snippet SHOULD work: <action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"/> <!-- if either of the above dialstrings is successful then this next line won't execute... --> <action application="bridge" data="sofia/gateway/quest/7325553828"/> I also noticed that you're using js in your example... I hope you will consider using the dialplan instead. The DP is quick and clean. At the very least, if you really need js for some logic then let the js do the logic and then transfer back out to the dialplan. That way you will use fewer system resources and your project can scale more easily. -MC
Hi Michael, Thanks for trying to help with this.
<action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"/> <!-- if either of the above dialstrings is successful then this next line won't execute... --> <action application="bridge" data="sofia/gateway/quest/7325553828"/>
In the dial plan above, consider that target is sitting at their 6095553828 phone. And that broadvox does not route to 6095553828 and passes me a NO_ROUTE_DESTINATION. The target will never get the call. So if I extend this to: <action application="bridge" data="sofia/gateway/broadvox/6095553828, sofia/gateway/broadvox/7325553828"/> <action application="bridge" data="sofia/gateway/quest/6095553828. sofia/gateway/quest/7325553828"/> In this plan you are not calling the numbers simultaneously if the broadvox is not able to route both calls. I can not see that you can stack this way and get the ability to call multiple destinations, so I must be missing something. "Call blast" or "Followme" is basically the functionality I am trying to implement. Separately we use multiple carriers. This is fairly common requirement. I am using .NET by the way - but point taken. Any other ideas on how to achieve multiple destinations with carrier failover would great! Thanks again. On Tue, Aug 11, 2009 at 2:07 PM, Michael Collins<msc@freeswitch.org> wrote:
On Tue, Aug 11, 2009 at 11:08 AM, Phillip Jones <pjintheusa@gmail.com> wrote:
Can you use this method to make simultaneous calls though while preserving carrier order? i.e. each call must try carrier 1 first then carrier 2 (because each carrier terminates a different subset of numbers)
So - if I did NOT want to support failover I would use:
session:execute("bridge", "sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"); << call 6095553828 and 7325553828 at the same time
If I were to use failover and not need multiple destinations then I would use:
session:execute("bridge", "sofia/gateway/broadvox/6095553828|sofia/gateway/quest/6095553828"); << call using broadvox first and quest it that fails
I need to combine:
Call 6095553828 and 7325553828 simultaneously and each trying broadvox then on fail quest.
session:execute("bridge",
"(sofia/gateway/broadvox/6095553828|sofia/gateway/quest/6095553828),(sofia/gateway/broadvox/7325553828,sofia/gateway/quest/7325553828)");
But of course that syntax does not work.
I can not see another syntax that would achieve this?
Just to make sure I'm reading you correctly I want to clarify...
You are trying to maintain carrier order and also trying to dial simultaneously. If I understand what you mean, you have two separate dialstrings that you want to dial simultaneously and if BOTH fail, THEN you want to dial the third dialstring?
If the above is correct then this dialplan snippet SHOULD work:
<action application="set" data="continue_on_fail=true"/> <action application="bridge" data="sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"/> <!-- if either of the above dialstrings is successful then this next line won't execute... --> <action application="bridge" data="sofia/gateway/quest/7325553828"/>
I also noticed that you're using js in your example... I hope you will consider using the dialplan instead. The DP is quick and clean. At the very least, if you really need js for some logic then let the js do the logic and then transfer back out to the dialplan. That way you will use fewer system resources and your project can scale more easily.
-MC
_______________________________________________ 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 Tue, Aug 11, 2009 at 1:43 PM, Phillip Jones <pjintheusa@gmail.com> wrote:
Hi Michael,
Thanks for trying to help with this.
<action application="set" data="continue_on_fail=true"/> <action application="bridge"
data="sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"/>
<!-- if either of the above dialstrings is successful then this next line won't execute... --> <action application="bridge" data="sofia/gateway/quest/7325553828"/>
In the dial plan above, consider that target is sitting at their 6095553828 phone. And that broadvox does not route to 6095553828 and passes me a NO_ROUTE_DESTINATION.
The target will never get the call.
So if I extend this to:
<action application="bridge" data="sofia/gateway/broadvox/6095553828, sofia/gateway/broadvox/7325553828"/> <action application="bridge" data="sofia/gateway/quest/6095553828. sofia/gateway/quest/7325553828"/>
In this plan you are not calling the numbers simultaneously if the broadvox is not able to route both calls. I can not see that you can stack this way and get the ability to call multiple destinations, so I must be missing something.
When you say "call multiple destinations" what exactly do you mean? If the Broadvox is unable to connect either call then the dialplan moves on to the Quest dial attempts. If that isn't what you need then can you clarify? Under what condition(s) would the dialplan need to attempt to call via Quest?
"Call blast" or "Followme" is basically the functionality I am trying to implement. Separately we use multiple carriers. This is fairly common requirement.
Yep, makes sense. Could you maybe write it out in pseudo code? Something like this: #1 Call phone numbers ABC and XYZ simultaneously via Broadvox #2 If BOTH ABC AND XYZ fail, then call ABC and XYZ via Quest
I am using .NET by the way - but point taken.
My mistake. :)
Any other ideas on how to achieve multiple destinations with carrier failover would great!
I'm 100% certain that this is possible with FreeSWITCH. You might just need a different approach, depending upon the circumstances with your carriers. Try the above suggestions first and let's see what happens. We'll take it from there. -MC
Thanks Michael, pseudo code would look this. 1) Call 6095556666 and 7325556666 simultaneously. 2a) As you dial 6095556666 go to the next carrier if you receive NO_ROUTE_DESTINATION. 2b) As you dial 7325556666 go to the next carrier if you receive NO_ROUTE_DESTINATION 3) The first number to answer and accept the call - bridge to leg a. Drop the other. Brian maintains that this can be done without loopback and loopback should never be used. Mike Jerris believes that loop back handles this and should be used. I am happy for all the help, but I am a bit confused at this stage. If this can not be done in the dailplan then I will need to pursue loopback and see how far I get with that. At the moment it works but not with bypass_media. As I said "call followme" and carrier failover are fairly common requirements so I do feel I am missing something. This must be implemented elsewhere. Again - thank you all for your help. You do a great job of getting getting your heads around all this stuff day in day out. Phillip Jones On Tue, Aug 11, 2009 at 3:19 PM, Michael Collins<msc@freeswitch.org> wrote:
On Tue, Aug 11, 2009 at 1:43 PM, Phillip Jones <pjintheusa@gmail.com> wrote:
Hi Michael,
Thanks for trying to help with this.
<action application="set" data="continue_on_fail=true"/> <action application="bridge"
data="sofia/gateway/broadvox/6095553828,sofia/gateway/broadvox/7325553828"/> <!-- if either of the above dialstrings is successful then this next line won't execute... --> <action application="bridge" data="sofia/gateway/quest/7325553828"/>
In the dial plan above, consider that target is sitting at their 6095553828 phone. And that broadvox does not route to 6095553828 and passes me a NO_ROUTE_DESTINATION.
The target will never get the call.
So if I extend this to:
<action application="bridge" data="sofia/gateway/broadvox/6095553828, sofia/gateway/broadvox/7325553828"/> <action application="bridge" data="sofia/gateway/quest/6095553828. sofia/gateway/quest/7325553828"/>
In this plan you are not calling the numbers simultaneously if the broadvox is not able to route both calls. I can not see that you can stack this way and get the ability to call multiple destinations, so I must be missing something.
When you say "call multiple destinations" what exactly do you mean? If the Broadvox is unable to connect either call then the dialplan moves on to the Quest dial attempts. If that isn't what you need then can you clarify? Under what condition(s) would the dialplan need to attempt to call via Quest?
"Call blast" or "Followme" is basically the functionality I am trying to implement. Separately we use multiple carriers. This is fairly common requirement.
Yep, makes sense. Could you maybe write it out in pseudo code? Something like this: #1 Call phone numbers ABC and XYZ simultaneously via Broadvox #2 If BOTH ABC AND XYZ fail, then call ABC and XYZ via Quest
I am using .NET by the way - but point taken.
My mistake. :)
Any other ideas on how to achieve multiple destinations with carrier failover would great!
I'm 100% certain that this is possible with FreeSWITCH. You might just need a different approach, depending upon the circumstances with your carriers. Try the above suggestions first and let's see what happens. We'll take it from there. -MC
_______________________________________________ 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
Just to add my $0.02-worth (if you're feeling generous..) - I don't think that the dialplan is expressive enough to do what's needed here, and that's where the trouble's coming from. It's not enormously tricky to build a generic "dial this set of numbers according to these rules" service using something hanging off the event socket - there's a writeup here: http://www.softivr.com/wiki/index.php/Find_me showing how it could be done on SoftIVR. To roll something similar yourself using the event socket, you'd need to map the dial function to 'originate', bridge to (IIRC) 'uuid_bridge', and have some way of passing messages around between the threads handling the different call legs, assuming that you're using one thread per leg. --Dave
It's also simple enough to write a plugin in one of the scripting languages to add an app to do exactly what you want... -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of David Knell Sent: Tuesday, August 11, 2009 1:55 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Loopback and bypass_media Just to add my $0.02-worth (if you're feeling generous..) - I don't think that the dialplan is expressive enough to do what's needed here, and that's where the trouble's coming from. It's not enormously tricky to build a generic "dial this set of numbers according to these rules" service using something hanging off the event socket - there's a writeup here: http://www.softivr.com/wiki/index.php/Find_me showing how it could be done on SoftIVR. To roll something similar yourself using the event socket, you'd need to map the dial function to 'originate', bridge to (IIRC) 'uuid_bridge', and have some way of passing messages around between the threads handling the different call legs, assuming that you're using one thread per leg. --Dave _______________________________________________ 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 / Michael - thanks for your your replies. The SoftIVR example is particularly useful. Must admit though - I was hoping not to have to do any custom stuff at this stage. It does appear there is no method to do this by staking bridge lines so I will put an issue in jira to try and get loopback working with bypass_media. In the meantime I will also start looking to build a custom bridging app. As I said though - not a road I wanted to go down. Thanks for your help! Phillip Jones On Tue, Aug 11, 2009 at 6:13 PM, Michael Giagnocavo<mgg@giagnocavo.net> wrote:
It's also simple enough to write a plugin in one of the scripting languages to add an app to do exactly what you want...
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of David Knell Sent: Tuesday, August 11, 2009 1:55 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Loopback and bypass_media
Just to add my $0.02-worth (if you're feeling generous..) - I don't think that the dialplan is expressive enough to do what's needed here, and that's where the trouble's coming from. It's not enormously tricky to build a generic "dial this set of numbers according to these rules" service using something hanging off the event socket - there's a writeup here: http://www.softivr.com/wiki/index.php/Find_me showing how it could be done on SoftIVR.
To roll something similar yourself using the event socket, you'd need to map the dial function to 'originate', bridge to (IIRC) 'uuid_bridge', and have some way of passing messages around between the threads handling the different call legs, assuming that you're using one thread per leg.
--Dave
_______________________________________________ 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
_______________________________________________ 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
perhaps we need to add some syntax + logic to originate: application="originate" data="(sofia/foo/bar|sofia/baz/bar),(sofia/foo/yum|sofia/baz/yum)" This would acomplish the equiv of loopback/bar,loopback/yum where bar and yum are then further expanded in the dialplan as sofia/foo/bar|sofia/baz/bar and sofia/foo/yum|sofia/baz/yum except that the threads of execution are handled directly by originate. I'm not sure that is really the "solution" since each () group would still have to be a separate thread to run independently. To me, loopback is the way to accomplish this issue (how I've done it with the same requirements that you have) since all the hard work is layered and works. The problem is that you require bypass_media which doesn't play nice with loopback. Perhaps have an on answer hook that tries to enable bypass media (re-invite) after the call is setup? On Wed, Aug 12, 2009 at 8:29 AM, Phillip Jones<pjintheusa@gmail.com> wrote:
David / Michael - thanks for your your replies. The SoftIVR example is particularly useful. Must admit though - I was hoping not to have to do any custom stuff at this stage.
It does appear there is no method to do this by staking bridge lines so I will put an issue in jira to try and get loopback working with bypass_media.
In the meantime I will also start looking to build a custom bridging app. As I said though - not a road I wanted to go down.
Thanks for your help!
Phillip Jones
On Tue, Aug 11, 2009 at 6:13 PM, Michael Giagnocavo<mgg@giagnocavo.net> wrote:
It's also simple enough to write a plugin in one of the scripting languages to add an app to do exactly what you want...
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of David Knell Sent: Tuesday, August 11, 2009 1:55 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Loopback and bypass_media
Just to add my $0.02-worth (if you're feeling generous..) - I don't think that the dialplan is expressive enough to do what's needed here, and that's where the trouble's coming from. It's not enormously tricky to build a generic "dial this set of numbers according to these rules" service using something hanging off the event socket - there's a writeup here: http://www.softivr.com/wiki/index.php/Find_me showing how it could be done on SoftIVR.
To roll something similar yourself using the event socket, you'd need to map the dial function to 'originate', bridge to (IIRC) 'uuid_bridge', and have some way of passing messages around between the threads handling the different call legs, assuming that you're using one thread per leg.
--Dave
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- -Rupa
Hi there,
application="originate" data="(sofia/foo/bar|sofia/baz/bar),(sofia/foo/yum|sofia/baz/yum)"
I agree. However, perhaps the ideal is not to specify the carriers at this level, as carriers are added and removed fairly often as costings change. So it would be nice to have some sort of proxy that resolves to a list of carriers: application="originate" data="sofia/MyCarriers/bar,sofia/MyCarriers/yum" <MyCarriers> <action application="carrier" data="sofia/foo"/> <action application="carrier" data="sofia/baz"/> <action application="carrier" data="sofia/etc"/> </MyCarriers> or something similar. This would achieve the same as loopback in this use case but without dangers of looping? Complicated stuff though.
Perhaps have an on answer hook that tries to enable bypass media (re-invite) after the call is setup?
That's a good idea - I will look into that. Thanks again. Phillip On Wed, Aug 12, 2009 at 10:22 AM, Rupa Schomaker<rupa@rupa.com> wrote:
perhaps we need to add some syntax + logic to originate:
application="originate" data="(sofia/foo/bar|sofia/baz/bar),(sofia/foo/yum|sofia/baz/yum)"
This would acomplish the equiv of
loopback/bar,loopback/yum where bar and yum are then further expanded in the dialplan as
sofia/foo/bar|sofia/baz/bar and sofia/foo/yum|sofia/baz/yum
except that the threads of execution are handled directly by originate. I'm not sure that is really the "solution" since each () group would still have to be a separate thread to run independently.
To me, loopback is the way to accomplish this issue (how I've done it with the same requirements that you have) since all the hard work is layered and works. The problem is that you require bypass_media which doesn't play nice with loopback.
Perhaps have an on answer hook that tries to enable bypass media (re-invite) after the call is setup?
On Wed, Aug 12, 2009 at 8:29 AM, Phillip Jones<pjintheusa@gmail.com> wrote:
David / Michael - thanks for your your replies. The SoftIVR example is particularly useful. Must admit though - I was hoping not to have to do any custom stuff at this stage.
It does appear there is no method to do this by staking bridge lines so I will put an issue in jira to try and get loopback working with bypass_media.
In the meantime I will also start looking to build a custom bridging app. As I said though - not a road I wanted to go down.
Thanks for your help!
Phillip Jones
On Tue, Aug 11, 2009 at 6:13 PM, Michael Giagnocavo<mgg@giagnocavo.net> wrote:
It's also simple enough to write a plugin in one of the scripting languages to add an app to do exactly what you want...
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of David Knell Sent: Tuesday, August 11, 2009 1:55 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Loopback and bypass_media
Just to add my $0.02-worth (if you're feeling generous..) - I don't think that the dialplan is expressive enough to do what's needed here, and that's where the trouble's coming from. It's not enormously tricky to build a generic "dial this set of numbers according to these rules" service using something hanging off the event socket - there's a writeup here: http://www.softivr.com/wiki/index.php/Find_me showing how it could be done on SoftIVR.
To roll something similar yourself using the event socket, you'd need to map the dial function to 'originate', bridge to (IIRC) 'uuid_bridge', and have some way of passing messages around between the threads handling the different call legs, assuming that you're using one thread per leg.
--Dave
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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
-- -Rupa
_______________________________________________ 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 Wed, Aug 12, 2009 at 10:22 AM, Phillip Jones<pjintheusa@gmail.com> wrote:
Hi there,
application="originate" data="(sofia/foo/bar|sofia/baz/bar),(sofia/foo/yum|sofia/baz/yum)"
I agree. However, perhaps the ideal is not to specify the carriers at this level, as carriers are added and removed fairly often as costings change. So it would be nice to have some sort of proxy that resolves to a list of carriers:
application="originate" data="sofia/MyCarriers/bar,sofia/MyCarriers/yum"
<MyCarriers> <action application="carrier" data="sofia/foo"/> <action application="carrier" data="sofia/baz"/> <action application="carrier" data="sofia/etc"/> </MyCarriers>
or something similar. This would achieve the same as loopback in this use case but without dangers of looping? Complicated stuff though.
Well, that is all done by mod_lcr. I was simplifying to narrow down to just originate. First we need to see if this is worth pursuing over fixing (modifying, whatever) loopback to handle bypass media. If it is, then I'll modify mod_lcr to deal with the situation in question (comma or pipe sep list of numbers to call. mod_lcr would then group as appropriate). Right now, my bridge is setup in a small javascript script that builds the appropriate dialstring (using loopback for external calls, user/ for internal calls) and then when doing the loopback call to mod_lcr to get the dialstring with all providers in the right order.
Perhaps have an on answer hook that tries to enable bypass media (re-invite) after the call is setup?
That's a good idea - I will look into that.
Thanks again.
Phillip
Let us know how it works for you... -- -Rupa
Rupa / all, Just a quick follow up to this. This is appears to a timing issue. If I try and do a "uuid_media off + uuid" in "api_after_bridge" it fails with "CHAN_NOT_IMPLEMENTED" and the call is dropped. If appears to be trying to do a SIP reinvite on the loopback channel which is of course just about to / has disappear/ed. So I tried this, after the call is established, at the commend line, I do "show calls" and using the uuid shown, type "uuid_media off uuid". The SIP REINVITE is issued and works. I think the switch_ivr_nomedia function in switch_ivr_c is getting the loopback uuid when it calls "other_uuid = switch_channel_get_variable(channel, SWITCH_BRIDGE_VARIABLE)" That's why the SIP REINVITE fails. So... in api_after_bridge I issue: "sched_api", "+3 none uuid_media off " + uuid. This calls the switch_ivr_nomedia function 3 seconds after the calls bridge is established. And it works, Not nice - not scalable or production ready - but the SIP-REINVITE is successful and at least now I understand what is going on. Make sense? Thanks Phil On Wed, Aug 12, 2009 at 12:21 PM, Rupa Schomaker<rupa@rupa.com> wrote:
On Wed, Aug 12, 2009 at 10:22 AM, Phillip Jones<pjintheusa@gmail.com> wrote:
Hi there,
application="originate" data="(sofia/foo/bar|sofia/baz/bar),(sofia/foo/yum|sofia/baz/yum)"
I agree. However, perhaps the ideal is not to specify the carriers at this level, as carriers are added and removed fairly often as costings change. So it would be nice to have some sort of proxy that resolves to a list of carriers:
application="originate" data="sofia/MyCarriers/bar,sofia/MyCarriers/yum"
<MyCarriers> <action application="carrier" data="sofia/foo"/> <action application="carrier" data="sofia/baz"/> <action application="carrier" data="sofia/etc"/> </MyCarriers>
or something similar. This would achieve the same as loopback in this use case but without dangers of looping? Complicated stuff though.
Well, that is all done by mod_lcr. I was simplifying to narrow down to just originate.
First we need to see if this is worth pursuing over fixing (modifying, whatever) loopback to handle bypass media. If it is, then I'll modify mod_lcr to deal with the situation in question (comma or pipe sep list of numbers to call. mod_lcr would then group as appropriate).
Right now, my bridge is setup in a small javascript script that builds the appropriate dialstring (using loopback for external calls, user/ for internal calls) and then when doing the loopback call to mod_lcr to get the dialstring with all providers in the right order.
Perhaps have an on answer hook that tries to enable bypass media (re-invite) after the call is setup?
That's a good idea - I will look into that.
Thanks again.
Phillip
Let us know how it works for you...
-- -Rupa
_______________________________________________ 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
Hi All, The reason it works when you wait 3 seconds is that mod_loopback bails out of the equation as soon as it detects a bridge. It'll call switch_ivr_uuid_bridge() and you'll end up with 2 sofia channels. Now the reason why you can't do uuid_media over a loopback channel is because it doesn't pass on SWITCH_MESSAGE_INDICATE_MEDIA and SWITCH_MESSAGE_INDICATE_NOMEDIA onto the underlying channel. The handler for those two events require accessing channel variables on the both channels to get the ip+port of where the audio should go through, so that mod_sofia can send a re-invite. Since mod_loopback is a completely different channel, it has its own channel variables, independent from mod_sofia (provided you have sofia channels on both side). That's why even sofia<>loopback won't do bypass media. On another note, mod_sofia will behave differently when it detects its being bridge with another sofia channel, providing optimizations when both call legs are SIP. My personal opinion is not to use mod_loopback unless absolutely necessary, FreeSWITCH's core is very flexible and there's often a (better) way than using mod_loopback. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 13-Aug-09, at 6:59 PM, Phillip Jones wrote:
Rupa / all,
Just a quick follow up to this.
This is appears to a timing issue. If I try and do a "uuid_media off + uuid" in "api_after_bridge" it fails with "CHAN_NOT_IMPLEMENTED" and the call is dropped.
If appears to be trying to do a SIP reinvite on the loopback channel which is of course just about to / has disappear/ed.
So I tried this, after the call is established, at the commend line, I do "show calls" and using the uuid shown, type "uuid_media off uuid". The SIP REINVITE is issued and works.
I think the switch_ivr_nomedia function in switch_ivr_c is getting the loopback uuid when it calls "other_uuid = switch_channel_get_variable(channel, SWITCH_BRIDGE_VARIABLE)"
That's why the SIP REINVITE fails.
So... in api_after_bridge I issue:
"sched_api", "+3 none uuid_media off " + uuid. This calls the switch_ivr_nomedia function 3 seconds after the calls bridge is established.
And it works, Not nice - not scalable or production ready - but the SIP-REINVITE is successful and at least now I understand what is going on.
Make sense?
Thanks
Phil
On Wed, Aug 12, 2009 at 12:21 PM, Rupa Schomaker<rupa@rupa.com> wrote:
On Wed, Aug 12, 2009 at 10:22 AM, Phillip Jones<pjintheusa@gmail.com> wrote:
Hi there,
application="originate" data="(sofia/foo/bar|sofia/baz/bar), (sofia/foo/yum|sofia/baz/yum)"
I agree. However, perhaps the ideal is not to specify the carriers at this level, as carriers are added and removed fairly often as costings change. So it would be nice to have some sort of proxy that resolves to a list of carriers:
application="originate" data="sofia/MyCarriers/bar,sofia/ MyCarriers/yum"
<MyCarriers> <action application="carrier" data="sofia/foo"/> <action application="carrier" data="sofia/baz"/> <action application="carrier" data="sofia/etc"/> </MyCarriers>
or something similar. This would achieve the same as loopback in this use case but without dangers of looping? Complicated stuff though.
Well, that is all done by mod_lcr. I was simplifying to narrow down to just originate.
First we need to see if this is worth pursuing over fixing (modifying, whatever) loopback to handle bypass media. If it is, then I'll modify mod_lcr to deal with the situation in question (comma or pipe sep list of numbers to call. mod_lcr would then group as appropriate).
Right now, my bridge is setup in a small javascript script that builds the appropriate dialstring (using loopback for external calls, user/ for internal calls) and then when doing the loopback call to mod_lcr to get the dialstring with all providers in the right order.
Perhaps have an on answer hook that tries to enable bypass media (re-invite) after the call is setup?
That's a good idea - I will look into that.
Thanks again.
Phillip
Let us know how it works for you...
-- -Rupa
_______________________________________________ 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
_______________________________________________ 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
The reason it works when you wait 3 seconds is that mod_loopback bails out of the equation as soon as it detects a bridge. It'll call switch_ivr_uuid_bridge() and you'll end up with 2 sofia channels.
Is there a hook that is fired when when that switch_ivr_uuid_bridge() successfully executes? So the uuid_media off is called on the appropriate sofia channels? Is "api_after_bridge" behaving correctly - should that only be called on the sofia channels and not the loopback? Is it being fired to early? On Thu, Aug 13, 2009 at 4:54 PM, Mathieu Rene<mrene_lists@avgs.ca> wrote:
Hi All,
The reason it works when you wait 3 seconds is that mod_loopback bails out of the equation as soon as it detects a bridge. It'll call switch_ivr_uuid_bridge() and you'll end up with 2 sofia channels.
Now the reason why you can't do uuid_media over a loopback channel is because it doesn't pass on SWITCH_MESSAGE_INDICATE_MEDIA and SWITCH_MESSAGE_INDICATE_NOMEDIA onto the underlying channel. The handler for those two events require accessing channel variables on the both channels to get the ip+port of where the audio should go through, so that mod_sofia can send a re-invite. Since mod_loopback is a completely different channel, it has its own channel variables, independent from mod_sofia (provided you have sofia channels on both side). That's why even sofia<>loopback won't do bypass media.
On another note, mod_sofia will behave differently when it detects its being bridge with another sofia channel, providing optimizations when both call legs are SIP.
My personal opinion is not to use mod_loopback unless absolutely necessary, FreeSWITCH's core is very flexible and there's often a (better) way than using mod_loopback.
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 13-Aug-09, at 6:59 PM, Phillip Jones wrote:
Rupa / all,
Just a quick follow up to this.
This is appears to a timing issue. If I try and do a "uuid_media off + uuid" in "api_after_bridge" it fails with "CHAN_NOT_IMPLEMENTED" and the call is dropped.
If appears to be trying to do a SIP reinvite on the loopback channel which is of course just about to / has disappear/ed.
So I tried this, after the call is established, at the commend line, I do "show calls" and using the uuid shown, type "uuid_media off uuid". The SIP REINVITE is issued and works.
I think the switch_ivr_nomedia function in switch_ivr_c is getting the loopback uuid when it calls "other_uuid = switch_channel_get_variable(channel, SWITCH_BRIDGE_VARIABLE)"
That's why the SIP REINVITE fails.
So... in api_after_bridge I issue:
"sched_api", "+3 none uuid_media off " + uuid. This calls the switch_ivr_nomedia function 3 seconds after the calls bridge is established.
And it works, Not nice - not scalable or production ready - but the SIP-REINVITE is successful and at least now I understand what is going on.
Make sense?
Thanks
Phil
On Wed, Aug 12, 2009 at 12:21 PM, Rupa Schomaker<rupa@rupa.com> wrote:
On Wed, Aug 12, 2009 at 10:22 AM, Phillip Jones<pjintheusa@gmail.com> wrote:
Hi there,
application="originate" data="(sofia/foo/bar|sofia/baz/bar), (sofia/foo/yum|sofia/baz/yum)"
I agree. However, perhaps the ideal is not to specify the carriers at this level, as carriers are added and removed fairly often as costings change. So it would be nice to have some sort of proxy that resolves to a list of carriers:
application="originate" data="sofia/MyCarriers/bar,sofia/ MyCarriers/yum"
<MyCarriers> <action application="carrier" data="sofia/foo"/> <action application="carrier" data="sofia/baz"/> <action application="carrier" data="sofia/etc"/> </MyCarriers>
or something similar. This would achieve the same as loopback in this use case but without dangers of looping? Complicated stuff though.
Well, that is all done by mod_lcr. I was simplifying to narrow down to just originate.
First we need to see if this is worth pursuing over fixing (modifying, whatever) loopback to handle bypass media. If it is, then I'll modify mod_lcr to deal with the situation in question (comma or pipe sep list of numbers to call. mod_lcr would then group as appropriate).
Right now, my bridge is setup in a small javascript script that builds the appropriate dialstring (using loopback for external calls, user/ for internal calls) and then when doing the loopback call to mod_lcr to get the dialstring with all providers in the right order.
Perhaps have an on answer hook that tries to enable bypass media (re-invite) after the call is setup?
That's a good idea - I will look into that.
Thanks again.
Phillip
Let us know how it works for you...
-- -Rupa
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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 Thu, Aug 13, 2009 at 6:54 PM, Mathieu Rene<mrene_lists@avgs.ca> wrote:
Hi All,
The reason it works when you wait 3 seconds is that mod_loopback bails
[snip] Thanks for that explanation. It umm.. explains a lot. :)
On another note, mod_sofia will behave differently when it detects its being bridge with another sofia channel, providing optimizations when both call legs are SIP.
My personal opinion is not to use mod_loopback unless absolutely necessary, FreeSWITCH's core is very flexible and there's often a (better) way than using mod_loopback.
So, I think the temp solution is to use loopback+delayed no media. but the real "solution" is to either drive the forked dialing logic externally (event socket) or consider supporting groupings in the bridge which.. umm... is gonna be a pain and will need buy in from from Tony and other core devs since that is a core (no pun intended) piece of code that nearly everything uses. I'm not sure I want to take a wack at it. -- -Rupa
Hi Rupa, What about my suggestion above introduce a "api_after_bridge" event that fires when the switch_ivr_uuid_bridge() bridges to the two sofia channels that Mathieu mentioned? Is that suggestion just way off the mark? If possible that would allow me to move forward - although I agree that supporting groupings of carriers is would be the most elegant solution. Let me know if I am just talking rubbish re the api_after_bridge" event. Thanks! Phillip Jones On Fri, Aug 14, 2009 at 2:33 AM, Rupa Schomaker<rupa@rupa.com> wrote:
On Thu, Aug 13, 2009 at 6:54 PM, Mathieu Rene<mrene_lists@avgs.ca> wrote:
Hi All,
The reason it works when you wait 3 seconds is that mod_loopback bails
[snip]
Thanks for that explanation. It umm.. explains a lot. :)
On another note, mod_sofia will behave differently when it detects its being bridge with another sofia channel, providing optimizations when both call legs are SIP.
My personal opinion is not to use mod_loopback unless absolutely necessary, FreeSWITCH's core is very flexible and there's often a (better) way than using mod_loopback.
So, I think the temp solution is to use loopback+delayed no media.
but the real "solution" is to either drive the forked dialing logic externally (event socket) or consider supporting groupings in the bridge which.. umm... is gonna be a pain and will need buy in from from Tony and other core devs since that is a core (no pun intended) piece of code that nearly everything uses.
I'm not sure I want to take a wack at it.
-- -Rupa
_______________________________________________ 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
Hi there, I created a feature request to cover this issue: http://jira.freeswitch.org/browse/FSCORE-422 - The ability to support Call FollowMe (or Call Blast) and multiple termination carriers - without Loopback If anybody wants comment on its merits and/or make the request clearer - that would be great. Thanks for every bodies help on this. Phillip Jones On Fri, Aug 14, 2009 at 3:17 PM, Phillip Jones<pjintheusa@gmail.com> wrote:
Hi Rupa,
What about my suggestion above introduce a "api_after_bridge" event that fires when the switch_ivr_uuid_bridge() bridges to the two sofia channels that Mathieu mentioned?
Is that suggestion just way off the mark? If possible that would allow me to move forward - although I agree that supporting groupings of carriers is would be the most elegant solution.
Let me know if I am just talking rubbish re the api_after_bridge" event.
Thanks!
Phillip Jones
On Fri, Aug 14, 2009 at 2:33 AM, Rupa Schomaker<rupa@rupa.com> wrote:
On Thu, Aug 13, 2009 at 6:54 PM, Mathieu Rene<mrene_lists@avgs.ca> wrote:
Hi All,
The reason it works when you wait 3 seconds is that mod_loopback bails
[snip]
Thanks for that explanation. It umm.. explains a lot. :)
On another note, mod_sofia will behave differently when it detects its being bridge with another sofia channel, providing optimizations when both call legs are SIP.
My personal opinion is not to use mod_loopback unless absolutely necessary, FreeSWITCH's core is very flexible and there's often a (better) way than using mod_loopback.
So, I think the temp solution is to use loopback+delayed no media.
but the real "solution" is to either drive the forked dialing logic externally (event socket) or consider supporting groupings in the bridge which.. umm... is gonna be a pain and will need buy in from from Tony and other core devs since that is a core (no pun intended) piece of code that nearly everything uses.
I'm not sure I want to take a wack at it.
-- -Rupa
_______________________________________________ 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 (7)
-
Brian West
-
David Knell
-
Mathieu Rene
-
Michael Collins
-
Michael Giagnocavo
-
Phillip Jones
-
Rupa Schomaker