VoIP Mailing List Archives

[odermann at googlemail...]

hi,

we are fighting with two flaws in fs and would be happy, if they could
be fixed. we are using socket outbound.

1.) hangup a call in ringing state:
this worked in one of the last fs versions, but suddenly does not work anymore.

let's say, we have an inbound call and do 3 originates to different
targets. all 3 targets are in ringing state. the target, which answers
first, will be bridged with the inbound call, the other two (still
ringing) targets should be hung up.

we do not want fs to hang up the other two originates automatically.
we want to hang up the other two originates by sending the hangups. we
set "hangup_after_bridge=false" and "park_after_bridge=true".
we do sendmsg hangup uuid. but the originates are first hung up, when
they are answered. when they are in ringing state, the hangup will do
nothing (anymore).

as i said, it worked before, so i assume, that something has changed
in the latest trunks.



2.) sendmsg uuid *whatever* can cause to excute the command on the wrong uuid:

let's say, we have an inbound call and an outbound call - at least we
thing we have it .
now we do for example sendmsg outbound_uuid hangup to hangup the
outbound call. but, if the uuid of the outbound call does not exist
(because there was a problem or something), the inbound will be hung
up instead.
the same happens with all sent messages to an uuid, which does not
exist. if we want to do a playback for the same outbound, the inbound
will hear it, if the outbound_uuid does not exist.

perhaps this is a feature, but i think that it would be nicer and more
reliable, if the sendmsg is only executed on the given uuid. if the
given uuid does not exist, nothing should happen or even nicer, an
event with an error should be sent to the socket.


thanks
dennis

_______________________________________________
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

[mike at jerris.com]

Can you please file bugs on http://jira.freeswitch.org with full sip
trace and FreeSWITCH debug output of these cases.


On Dec 8, 2008, at 4:28 AM, Dennis wrote:

[anthony.minessale at g...]

#2 was because when you sendmsg with no uuid on an outbound socket it defaults to the session who called you.
I changed to code to make a distinction between not supplying a uuid and supplying an invalid uuid.

#1 seems hard to believe. Please provide a console trace of the channel *ignoring* the hangup command.


On Mon, Dec 8, 2008 at 3:28 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[odermann at googlemail...]

[anthony.minessale at g...]

try the sendmsg issue again

are you doing the hangup with

api uuid_kill <uuid>



On Mon, Dec 8, 2008 at 9:47 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[odermann at googlemail...]

i have to shift places. will be back in a few minutes and test.

no, we are using the simple sendmsg uuid hangup. as far as we
remember, we do not use api uuid_kill, because we do not get a hangup
event with this.


2008/12/8 Anthony Minessale <anthony.minessale@gmail.com>:

[anthony.minessale at g...]

you would get a hangup event in either case.


On Mon, Dec 8, 2008 at 10:19 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[anthony.minessale at g...]

channels in originate were not checking for private events.
now they should but if send them commands to do crazy stuff like play a file while they are
in the middle of originating there could be ill side effects (e.g. play file before media was established etc which could cause the call to abort)

btw you can send

call-command: hangup
hangup-cause: normal_clearing

in place of
call-command: execute
execute-app-name: hangup
execute-app-arg: normal_clearing


On Mon, Dec 8, 2008 at 10:56 AM, Dennis <odermann@googlemail.com (odermann@googlemail.com)> wrote:

[odermann at googlemail...]

thanks, now it works as we expected.

and thanks for the hint, how we should send the hangup with sendmsg.
we will do it your way


2008/12/8 Anthony Minessale <anthony.minessale@gmail.com>:

[jan.kubr at gmail.com]

[mike at jerris.com]

On Dec 9, 2008, at 6:52 AM, Jan Kubr wrote: