[Freeswitch-users] ESL connection appears to hang on bgapi originate - isn't the whole point of it being in the background?

[Michael Avers]

Hello,

When an ESL connection is opened to FS, there is no way to close the connection with "exit" until the A Leg of a bgapi originate answers or rejects the call, or the originate times out.

I thought bgapi is supposed to be truly non-blocking?

When the bgapi originate is executed, FS returns the expected *Reply-Text: +OK Job-UUID *response, I am able to continue to communicate with FS over the ESL connection while the originate is in progress and the A Leg is ringing, and get responses to other standard commands. It all works, except for "exit", to which FS responds with *Reply-Text: +OK bye *but does not actually proceed to close the connection and issue a *Content-Type: text/disconnect-notice *response until the (supposedly in the background) originate is rejected or answered. However, after the exit command, ESL will no longer process any new commands, it just hangs until the originate has some kind of result.

I tested with FS 1.6.2, a 1.8.x instance, and also latest master just now.

This is an actual telnet ESL connection, just added a comment to indicate where it appears to "hang":

Trying 45.45.45.45...
Connected to 45.45.45.45.
Escape character is '^]'.
Content-Type: auth/request

auth ClueCon

Content-Type: command/reply
Reply-Text: +OK accepted

bgapi originate {origination_caller_id_number='4154446666',origination_caller_id_name='Callback',originate_timeout=20}user/1000 at sip.domain.com 808080 XML sip.domain.com

Content-Type: command/reply
Reply-Text: +OK Job-UUID: e53965cd-b0c0-4c39-99ad-946048082ef2
Job-UUID: e53965cd-b0c0-4c39-99ad-946048082ef2

exit

Content-Type: command/reply
Reply-Text: +OK bye

*<< here it pauses until originate times out, gets rejected, or answered by the destination user >>*

Content-Type: text/disconnect-notice
Content-Length: 67

Disconnected, goodbye.
See you at ClueCon! http://www.cluecon.com/
Connection closed by foreign host.

Is this expected behavior? I also tested with ignore_early_media on/off just in case, same result.

Thanks
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20191018/6465292b/attachment.html>