VoIP Mailing List Archives

[odermann at googlemail...]

hi,

i am using socket outbound and want to bridge two calls with each other.

i do the following:

a call comes in and it gets answered (inbound call). after i send the
answer to the inbound, i do an originate to &park (outbound).
after i answered the outbound, i want both sides to be able to talk to
each other. but when i try uuid_bridge <inbound-uuid> <outbound-uuid>
it does not work. i do not even get a channel_bridge or something.

when i do 2 originates and send them to &park(), i can bridge them
with each other with uuid_bridge.

what am i doing wrong?

the other question is, how to unbridge two calls, if they are bridged?
i can't find anything like an unbridge command.


thanks
dennis93

_______________________________________________
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

[birgit at westhawk.co.uk]

Hi Dennis,

I had a similar problem, but we're using javascript, not sockets.

Is there any reason why your first original and then bridge instead of
bridging your inbound call immediately to the (what will be your)
outbound call?

If that doesn't work, I had to take a channel out of a conference call
and bridge that channel to a new person. I used 'intercept' in the end:

var sSession = new
Session("{ignore_early_media=true,originate_timeout=10}" +
customer_service_url);
sSession.setAutoHangup(false);
sSession.execute("intercept", uuid);

where sSession is the newly (latest) originated call
and uuid the identifier of the channel in the conference call.


As far as I know, 'unbridge' as command doesn't exist.
I wouldn't know how to achieve that.

Hope the above helps.

Cheers, Birgit


On 05/11/08 15:05, Dennis wrote:

[odermann at googlemail...]

hi birgit,

thanks for your reply!

some days ago anthony told me about "intercept" in the irc, but i seem
not to be able to use it, at least not for connecting two channels
with each other.

we need to first originate, because we want to have complete control
over all channels and chose, what to do with them.

what we have, is an answered inbound channel and an originate at
&park(). let's say, we play a soundfile for the originated channel
(outbound) and then want connect both channels with each other.

when we sendmsg intercept <uuid> (the uuid is the uuid of the
inbound), we get channel_execute intercept and
channel_execute_complete intercept for call-direction outbound. but we
can not talk to each other and won't get any more information about
the status.

do you have a clue, what the problem could be or what we could try else?


regards,
dennis



2008/11/5 Birgit Arkesteijn <birgit@westhawk.co.uk>:

[birgit at westhawk.co.uk]

Hi Dennis,

No, sorry, my knowledge of FreeSWITCH is still rather limited.
Hopefully someone else on the list will know.

Cheers, Birgit


On 06/11/08 09:14, Dennis wrote:

[anthony.minessale at g...]

If that doesn't work one of your uuids are wrong or contains a superfluous space or some other character
You have to understand that the inbound call that uses "socket" is the same thing as &park()
They are both in a park state at that point and there is no functional difference.

once both channels are answered and in the park state,
you have 2 choices and they both work, so watch the console log on debug level to find your mistake.

api uuid_bridge <uuid> <other_uuid>
sendmsg to <uuid> with call-command: execute to execute intercept on <other_uuid>

to prove it, just set your script to accept and answer the inbound call then make the outbound call and do nothing more.
Then at the CLI type:

[odermann at googlemail...]

hi anthony,

i just pasted the results of 3 unsuccessful tests into the pastebin:
http://pastebin.freeswitch.org/6018

perhaps you could be so nice and have a look at it...

in the first test i made an uuid-bridge over our socket script.
in the second test i made an originate and then an intercept (which
shows an error in the debug log).
in the last test, i entered to uuid-bridge into the cli.


some more information arround the whole thing:

1.) the uuid's must be correct, because we can do everything with the
inbound and the outbound by sending messages with the uuid of the leg,
we want to talk to.

2.) if we make two originates, so that we have 2 outbound legs, we are
able to uuid-bride the two outbound legs with each other. it simply
does not work with the inbound...


thanks
dennis



2008/11/6 Anthony Minessale <anthony.minessale@gmail.com>:

[anthony.minessale at g...]

in your intercept example there is no uuid (note the empty () where the uuid should be and the syntax error)

1. 2008-11-06 16:17:26 [DEBUG] switch_ivr.c:391 switch_ivr_parse_event() sofia/internal/1001@192.168.2.2 Command Execute intercept()
   
   
2. 2008-11-06 16:17:26 [ERR] mod_dptools.c:256 intercept_function() Usage: [-bleg] <uuid>
   

in the cli example you specified one of the uuids from the wrong call it should have been.

b05f58aa-ac16-11dd-9f4b-f1b593b2c0b8 b0714c7c-ac16-11dd-9f4b-f1b593b2c0b8

you had an existing bridged call and you used one of the uuid from that call instead of your parked calls.

the one you specified was in a bridge already.






On Thu, Nov 6, 2008 at 9:54 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[odermann at googlemail...]

but what could be the cause, that there is no uuid in the intercept?
we are sending the uuid of the outbound with the intercept.

as you can see under http://pastebin.freeswitch.org/6019 in the "test
intercept" part, we send the message with the uuid and get the answer
below (with intercept, outbound and the uuid of the outbound ->
in_uuid is the inbound uuid).
so i can not understand, why the uuid of the intercept is empty.

i was testing with two softphones, which are connected to the standard
1000 and 1001. this might be the reason, why there were 4 calls in the
cli.


i now tested over our carrier, so that there are only two uuid's. the
result is the same with only two possible uuid's (see log in
http://pastebin.freeswitch.org/6019).

i really have no clue, what i am doing wrong.

thanks a lot
dennis



2008/11/6 Anthony Minessale <anthony.minessale@gmail.com>:

[anthony.minessale at g...]

you are missing execute-app-arg

sendmsg <the uuid of the channel you want to control (inbound leg) >
call-command: execute
execute-app-name: intercept
execute-app-arg: <the uuid of the call you want to bridge to (outbound leg) >


On Thu, Nov 6, 2008 at 11:18 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[odermann at googlemail...]

ok, now i understand to way intercept should work (i was always
wonderung, why there only was one uuid).

BUT, it still does not work. Could you please be so kind and have a
look at http://pastebin.freeswitch.org/6033. there you can see the
results of our latest tests.


1.) intercept with inbound-uuid and (originated) outbound-uuid (now
the right way) => does not work for us.


2.) uuid_bridge with inbound-uuid and (originated) outbound-uuid =>
does not work for us.
this does not work either. we do not get any events with
channel_bridge or something. after we make a bridge, nothing happens
till we hang up.

might it be possible, that there is a reason that i does not work and
that the reason is the same because intercept does not work?


3.) uuid_bridge with two originated calls => WORKS
we have an inbound call and then we make two originates. then we
uuid_bridge both originated calls. we can talk to each other and get
all channel events like bridge and unbridge.

it seems, that there is a problem, when we want to do the whole thing
with the inbound.

the only problem is, that we originate both calls with
hangup_after_bridge=false, but as soon as one of the bridged
originated calls hangs up, the other call is also beeing hangup.


we just can't see, what we are doing wrong or what we could try or
change to make it work.


thanks,
dennis



2008/11/6 Anthony Minessale <anthony.minessale@gmail.com>:

[brian at freeswitch.org]

On Nov 7, 2008, at 4:30 AM, Dennis wrote:

[anthony.minessale at g...]

Notice the one that works is the one you are typing from the cli.

maybe your event socket client code is not coded right?
Are you adding 2 <CR> to the end of every event?
Are you reading in the appropriate bytes from the Content-Length header?

The example of uuid_bridge from your program looks like a canceled outbound call.
what steps are you taking to do this?

Again try it from the CLI to prove it works.

* Make an extension that just calls answer and park and call it inbound.
<action application="answer"/>
<action application="park"/>

* call the extension and note the channel hitting the dialplan.

* show channels to confirm it's there.

* at the cli type the following to establish and park the outbound leg
originate sofia/internal/user@host.com (user@host.com) &park()

* show channels again to now see 2 parked calls.

* type in the uuid_bridge command with the 2 uuid


This is the exact equivalent of what you are doing.


FYI, i added a new var you can set called "park_after_bridge" that will automatically return
the A leg to park after a completed bridge if that leg is still active.

make sure not to do any other calls at the same time to avoid adding extra info to the
logs that make it harder to debug.




On Fri, Nov 7, 2008 at 4:30 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[odermann at googlemail...]

anthony, brian,

you are right. it really works the way anthony described over the cli.

under http://pastebin.freeswitch.org/6038 you can find the debug log
of the working uuid_bridge and of another not working uuid_bridge over
the socket and our script.

in our second test we made the inbound over the socket and an
originate from our script. then we changed into the cli, entered show
channels and made an uuid_bridge with the two shown uuid's. this did
not work. the call goes immediately into sleep. but the two shown
uuid's must be correct, right?

is there a way to see in the debug, where our problem might be? what
do we have to look for? we start to get creazy...
is it possible, that the inbound is in a wrong state, so that we have
those problems?

[odermann at googlemail...]

an addition:

if we make a call to our socket (inbound), we get the following error
in our log:

2008-11-07 16:58:57 [ERR] switch_ivr.c:498 switch_ivr_park() Cannot
park channels that are under control already.

if an inbound comes in, we send a connect, then a park and then an
answer - nothing else.

directly after we sendmsg park, we get the error above...

_______________________________________________
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 at g...]

Can you capture the whole log from the instant you get the inbound call until you give up on the uuid bridge?
I don't see any of the log about your outbound call.

are you doing

api originate sofia/internal/user@host &park()

For the outbound call like the cli example?

The socket application *is* park. You do not need to tell it to park.

as soon as you get the new inbound connection from calling socket app
all you need to do is answer it.

In your code when you fork are you closing the socket in the parent side so it's not
in use by both processes?


stop by irc if you have more questions we can chat in real time.



On Fri, Nov 7, 2008 at 10:10 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote: