search

0x19 / goesl

Freeswitch Event Socket Library wrapper for Go
https://godoc.org/github.com/0x19/goesl
MIT License
127 stars 124 forks source link

Connection is closed on first unsuccessful result #24

Closed babakyakhchali closed 4 years ago

babakyakhchali commented 4 years ago

Hi I'm using this library to control calls using a client connection to freeswitch. Each call is parked in xml dialplan and on receiving park event my client application starts controlling the call by executing apps on channel using SendMsg. But if any app execution results in an error, for example calling execute on an already destroyed channel, whole esl socket is closed. Is there anyway to prevent such behaviour and continue receiving events? thanks

bcorrigeux commented 4 years ago

are you using the example client design?

babakyakhchali commented 4 years ago

yes I am. When error occurs on line 49, for example some api calls fails with -ERR, main socket is closed

bcorrigeux commented 4 years ago

can you share the code you are using? it sounds like you are not using things like client.BgApi("uuid_kill uuid") ? im not having problems with it returning errors unless i restart freeswitch without restarting my application however i do think the library is a little hasty in blowing away the connection. i wrote some reconnection code which required slightly modifying the library at https://github.com/bcorrigeux/goesl but most of the magic happens outside of the library but i should be able to give you a summary of what i did if you end up wanting to use it. i may push it into the library but it hasnt seemed necessary yet.

you can also go into the library and simply remove the lines done <- true break from the Handle() function but this may not be cause unexpected problems that i am not aware of. but from my small amount of testing it worked fine.

babakyakhchali commented 4 years ago

thanks @bcorrigeux When your are sending commands to control multiple calls, one of them may return an error which causes main socket to close, but I think this should not happen, may be the problems is this line this should not return an error because the message structure is correct but some api call resulted in error...

bcorrigeux commented 4 years ago

yeah that looks correct to me, probably needs to be fixed on the other message types as well. you can try making a pr but this repo is not very kept up.

babakyakhchali commented 4 years ago

Yes you are right. Thanks for sharing your thoughts about the problem