So you need to create a second call leg that is somewhat independent of the first leg, so that you can play a file, and *then* bridge the new leg to the "current" leg?
I just want to make sure that I grok what you are trying to accomplish. Also, if you haven't put your dialplan and script in pastebin then it would be good to do so for the sake of everyone being on the same page. ( pastebin.freeswitch.org) -MC On Tue, Oct 21, 2008 at 9:26 AM, Dennis <[EMAIL PROTECTED]> wrote: > 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. > > 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> wrote: > >> > >> 2008/10/20 Anthony Minessale <[EMAIL PROTECTED]>: > >> > >> >> 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/[EMAIL PROTECTED]"); > >> > >> 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/[EMAIL PROTECTED] > >> 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 >
_______________________________________________ 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