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