you *need* park because you have to have somewhere to anchor the call to and the park function is the routine<br>that actually parses all the DTMF and the commands you send the channel with sendmsg etc.<br><br>I would have to look into refactoring it so when there is no media on the channel, it would sleep in place<br>
of reading audio but if you send it any instruction that required media like playback etc it would still instantly send<br>a 183.<br><br>Don't forget we are a b2bua here so proxying calls is only smoke and mirrors for us.<br>
<br>Just as if you put a playback "please_wait.wav" before bridge, when you try to use a media enabled app<br>it will automatically generate a 183 to establish early media to make it possible.<br><br>I'll see what I can do, it may be difficult to avoid regressions, don't forget my wishlist if i pull it off ;)<br>
<br><br><br><br><div class="gmail_quote">On Wed, May 13, 2009 at 2:30 AM, Mikael Aleksander Bjerkeland <span dir="ltr"><<a href="mailto:mikael@bjerkeland.com">mikael@bjerkeland.com</a>></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;">
I've been looking for something like this as well, to make the outbound<br>
event socket behave more like FastAGI and handle the logic.<br>
<br>
<br>
El mié, 13-05-2009 a las 00:12 -0700, ibrahim tunali escribió:<br>
<div class="im">> "nopark" option would be great. FS sends "100 trying" while opening socket<br>
> and leg A waits other responses from socket. If I send pre-answer command it<br>
> reply via 183 early media and activate RTP path.<br>
><br>
> Regards,<br>
> ibrahim<br>
><br>
><br>
> David Knell wrote:<br>
> ><br>
> > Gotcha - but in the case where the call hasn't yet got to a point where<br>
> > there's a 183 been sent then I guess this wouldn't apply - there<br>
> > shouldn't be any audio from the far end at this point, nor would the far<br>
> > end be expecting any.<br>
> ><br>
> > I'd suggest (and would volunteer to knock together a patch) adding a<br>
> > 'nopark' option to the socket command, which doesn't park the call - nor<br>
> > would it change existing behaviour. Obviously, in a situation like that<br>
> > outlined by Ibrahim where the socket app handles all aspects of the<br>
> > call, then it'll need to make sure that it signals ringing, answer or<br>
> > whatever to make the call state flow work.<br>
> ><br>
> > --Dave<br>
> ><br>
> ><br>
><br>
<br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<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>
</div></div></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>