Hi Dennis
I think I have problems to understand what is happening in detail.
Just a short explaination, of what we are doing. We use socket outbound and have a PHP script, which is listening to "myevents". If a new call is coming in, we fork the PHP script in a new process to handle this call. Now we have a new "inbound", which we can handle with fs and the PHP script. In example, we play a file for the caller. After we have played the file, we want to call to the dialed number. But we do not want to connect both call immediately. We originate to the target number, because we want to play a file, before we connect, perhaps. A "bridge" would connect both legs immediately. Therefore we need to originate.
If we originate, the originated call will run in a new child process in PHP (this does not happen with "bridge").
How could our PHP "inbound"-process know, what the "outbound"-process is doing? They have nothing to do with each other.
That's some basic IPC. The way I've done it is to create a database table which holds information about each call, keyed from the call's UUID. It's not hugely efficient, but works..! But each call has to know about the other. So you need to pass the first call's UUID to the second one, which can be done like so (in Perl, but should translate to PHP pretty easily): print $sock "bgapi originate {3c_uuid=$uuid}sofia/gateway/number &application(or whatever)\n\n"; Now your outbound call has a channel variable called 3c_uuid, which holds the UUID of your inbound leg. From this point onwards, the outbound can talk to the inbound and, if it includes a way of replying, the inbound can talk to the outbound. There's plenty of other ways of establishing IPC - one which comes to mind is to listen on a socket on the inbound leg, and pass the port to the outbound one. Hope this helps.. Cheers -- Dave
We have an inbound and then we play a file. The current process "knows", that we have to make an originate, play a file and then bridge. But the "current" process does not know, when the playfile is done and the bridge can be executed.
So how could we "control both sessions individually"?
Sorry for all these questions, but we have serious problems, because we can not find the answers.
Thanks Dennis
2008/10/21 Anthony Minessale <anthony.minessale@gmail.com>:
once you are controlling both sessions individually use api to send the uuid_bridge command:
api uuid_bridge <uuid of leg a> <uuid of leg b>
On Tue, Oct 21, 2008 at 9:37 AM, Dennis <odermann@googlemail.com> wrote:
2008/10/20 Anthony Minessale <anthony.minessale@gmail.com>:
A more precise question about inbound/outbound: I want to read out the events from freeswitch with my PHP-script and then tell freeswitch, what to do next. I have the feeling, that "outbound" is the way to go. But of course I also want to be able to start calls. Can I do this by using "outbound"?
yes
But what is the difference between "bridge" and "originate" in handling dials? "bridge" connects two calls together, but "originate" seems to be a part of "bridge". If we make a "bridge", both legs seem to bee in the same session, when using socked outbound.
We make a "bridge" as follows: $this->invokeMessage("bridge", "sofia/internal/1001@192.168.1.5");
When we use "originate" (which we prefer, because we do not want to connect both call with each other immediately), we use the following command: $this->invokeCommand("API originate {origination_caller_id_number=123455}sofia/internal/1001@192.168.1.5 123");
The problem is, that the new call is now in another call-session and we do not know how to bring the calls together.
Does it have something to do with "API"? If yes, is there a way to use "originate" with "sendmsg"?
_______________________________________________ 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