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
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:
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
#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> wrote:
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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
#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.
anthony, thanks for the quick reaction! we just tested you changes and it works the opposite way it should. this means: when we do not send an uuid, we get an an error (Reply-Text => -ERR invalid session id []). if we send a wrong/not existing uuid, the command will be executed on the inbound uuid.
#1 seems hard to believe. Please provide a console trace of the channel *ignoring* the hangup command.
i know it is hard to believe, we didn't believe it either ;-) have a look at http://pastebin.freeswitch.org/6367 what we simply do here: the inbound is coming in, then we do an originate and hang up the inbound. then we directly send a hangup for the outbound. the outbound will go on ringing. then, when the ringing outbound is answered, we directly get the hangup. fs gets the hangup and remembers it, but seems to wait till the answer to execute this command.
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> wrote:
#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.
anthony, thanks for the quick reaction!
we just tested you changes and it works the opposite way it should.
this means: when we do not send an uuid, we get an an error (Reply-Text => -ERR invalid session id []). if we send a wrong/not existing uuid, the command will be executed on the inbound uuid.
#1 seems hard to believe. Please provide a console trace of the channel *ignoring* the hangup command.
i know it is hard to believe, we didn't believe it either ;-)
have a look at http://pastebin.freeswitch.org/6367
what we simply do here: the inbound is coming in, then we do an originate and hang up the inbound. then we directly send a hangup for the outbound. the outbound will go on ringing. then, when the ringing outbound is answered, we directly get the hangup. fs gets the hangup and remembers it, but seems to wait till the answer to execute this command.
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
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>:
try the sendmsg issue again
are you doing the hangup with
api uuid_kill <uuid>
you would get a hangup event in either case. On Mon, Dec 8, 2008 at 10:19 AM, Dennis <odermann@googlemail.com> wrote:
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>:
try the sendmsg issue again
are you doing the hangup with
api uuid_kill <uuid>
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
you would get a hangup event in either case.
yes, you are right. we just tested and saw that. the reason for sendmsg hangup, was the sometimes useful event-lock. it works with api uuid_kill as we wanted. but with sendmsg hangup it still does not work. shouldn't sendmsg hangup work like uuid_kill here? how useful could it be, to let it ring, when the hangup was already sent and is immediately executed when the anser is sent? #2 now works perfectly. thanks for the great support!
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> wrote:
you would get a hangup event in either case.
yes, you are right. we just tested and saw that. the reason for sendmsg hangup, was the sometimes useful event-lock.
it works with api uuid_kill as we wanted. but with sendmsg hangup it still does not work. shouldn't sendmsg hangup work like uuid_kill here? how useful could it be, to let it ring, when the hangup was already sent and is immediately executed when the anser is sent?
#2 now works perfectly. thanks for the great support!
_______________________________________________ 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 II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
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>:
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> wrote:
you would get a hangup event in either case.
yes, you are right. we just tested and saw that. the reason for sendmsg hangup, was the sometimes useful event-lock.
it works with api uuid_kill as we wanted. but with sendmsg hangup it still does not work. shouldn't sendmsg hangup work like uuid_kill here? how useful could it be, to let it ring, when the hangup was already sent and is immediately executed when the anser is sent?
#2 now works perfectly. thanks for the great support!
_______________________________________________ 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 II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400
_______________________________________________ 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
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
What is the difference this makes? Just curious because I've been using the latter as well.
we just tested you changes and it works the opposite way it should.
this means: when we do not send an uuid, we get an an error (Reply-Text => -ERR invalid session id []). if we send a wrong/not existing uuid, the command will be executed on the inbound uuid.
This hasn't been changed, has it? On the latest trunk, if I don't pass the uuid, I get "-ERR invalid session id". I can always pass it explicitly though, so no big deal. Jan Kubr
On Dec 9, 2008, at 6:52 AM, Jan Kubr wrote:
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
What is the difference this makes? Just curious because I've been using the latter as well.
we just tested you changes and it works the opposite way it should.
this means: when we do not send an uuid, we get an an error (Reply-Text => -ERR invalid session id []). if we send a wrong/not existing uuid, the command will be executed on the inbound uuid.
This hasn't been changed, has it? On the latest trunk, if I don't pass the uuid, I get "-ERR invalid session id". I can always pass it explicitly though, so no big deal.
Jan Kubr
We did have confirmation from others that this is working properly now. Can you please make sure you are on current trunk and re-test this. Mike
participants (4)
-
Anthony Minessale
-
Dennis
-
Jan Kubr
-
Michael Jerris