#2 was because when you sendmsg with no uuid on an outbound socket it defaults to the session who called you.<br>I changed to code to make a distinction between not supplying a uuid and supplying an invalid uuid.<br><br>#1 seems hard to believe.&nbsp; Please provide a console trace of the channel *ignoring* the hangup command.<br>
<br><br><div class="gmail_quote">On Mon, Dec 8, 2008 at 3:28 AM, Dennis <span dir="ltr">&lt;<a href="mailto:odermann@googlemail.com">odermann@googlemail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
hi,<br>
<br>
we are fighting with two flaws in fs and would be happy, if they could<br>
be fixed. we are using socket outbound.<br>
<br>
1.) hangup a call in ringing state:<br>
this worked in one of the last fs versions, but suddenly does not work anymore.<br>
<br>
let&#39;s say, we have an inbound call and do 3 originates to different<br>
targets. all 3 targets are in ringing state. the target, which answers<br>
first, will be bridged with the inbound call, the other two (still<br>
ringing) targets should be hung up.<br>
<br>
we do not want fs to hang up the other two originates automatically.<br>
we want to hang up the other two originates by sending the hangups. we<br>
set &quot;hangup_after_bridge=false&quot; and &quot;park_after_bridge=true&quot;.<br>
we do sendmsg hangup uuid. but the originates are first hung up, when<br>
they are answered. when they are in ringing state, the hangup will do<br>
nothing (anymore).<br>
<br>
as i said, it worked before, so i assume, that something has changed<br>
in the latest trunks.<br>
<br>
<br>
<br>
2.) sendmsg uuid *whatever* can cause to excute the command on the wrong uuid:<br>
<br>
let&#39;s say, we have an inbound call and an outbound call - at least we<br>
thing we have it ;-).<br>
now we do for example sendmsg outbound_uuid hangup to hangup the<br>
outbound call. but, if the uuid of the outbound call does not exist<br>
(because there was a problem or something), the inbound will be hung<br>
up instead.<br>
the same happens with all sent messages to an uuid, which does not<br>
exist. if we want to do a playback for the same outbound, the inbound<br>
will hear it, if the outbound_uuid does not exist.<br>
<br>
perhaps this is a feature, but i think that it would be nicer and more<br>
reliable, if the sendmsg is only executed on the given uuid. if the<br>
given uuid does not exist, nothing should happen or even nicer, an<br>
event with an error should be sent to the socket.<br>
<br>
<br>
thanks<br>
dennis<br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>