QUESTION: events per socketConnection or not

[MehSha]

it may seem naive, but i really do not know if the events are streamed per call (socketConnection) or all the events of all calls are received in every connection. I mean, if i want to listen to DTMF in calls, and have two simultaneous calls, if call A send 1 and call b send 2, is this the case that both calls receive both events? or every call receives it's related event (call A, 1 and call B, 2). if the first is the case,isn't it a good idea to filter events for calls based on call_uuid and let pertinent calls have pertinent events?

[0x19]

Hmm so how it works is that goesl client is a raw connection towards freeswitch esl. It's designed to be one connection to rule them all so you will get all events within single connection. It's up to you to manage specific events and their states.

Each DTMF event will be related to leg that actually initialized DTMF event. So to answer your question, No. Each call will receive its related event. Other call, unless intentional, won't receive that event. If you have leg A and leg B connected on the same call than when leg A ships event, B leg will receive it. Same happens with reversed order.

Now don't get me fully for my word but I think that all of this can be modified within freeswitch config. I've just never went that deep. Didn't need to yet.

[MehSha]

thanks for your reply, so is the case for other events like CHANNEL_HANGUP, CHANNEL_EXECUTE_COMPLETE etc? then we really need to separate events based on call_uuid, let any call has it's own events. what i am doing is to put a layer on top of goesl to allow for easy IVR creation like call.play("hello.wav") fmt.Println("Played!") num = call.playAndGetDgits("enter.wav", 2, 4, 5000) fmt.Println("hoorai", num)

(calls block until we get CHANNEL_EXECUTE_COMPLETE for that application for easy synchronous IVR logic)

I need listen to call events and process them that I encountered issue#1 and got this question. thanks for your help and if you have plan for any improvement for goesl I am in, (i have not seen any issue or roadmap)

[0x19]

Check this one out :D

https://github.com/0x19/goesl/blob/master/examples/server_playback.go#L75

[MehSha]

I have seen this but it does not allow for synchronous logic. I want to execute next line of code when playback is completed. thanks

[0x19]

You have 3rd parameter that can help you with that :)

https://github.com/0x19/goesl/blob/master/connection.go#L61

From http://wiki.freeswitch.org/wiki/Event_Socket_Outbound

Examples
Here are examples of how to use it in the dialplan.
<action application="socket" data="127.0.0.1:8084"/>
<action application="socket" data="127.0.0.1:8084 async"/> 
<action application="socket" data="127.0.0.1:8084 full"/>
<action application="socket" data="127.0.0.1:8084 async full"/>

Note about async mode
If you are using async, you need to pay attention to potential race condition. The commands you send may not execute in sequential order. You may force the command to wait:
sendmsg 
call-command: set
execute-app-name: foo=bar\n\n
event-lock:true

[MehSha]

Thank for your guides, but third option keeps freeswitch in lock state, but does not help with go code to be kept locked. On Sep 22, 2015 3:44 PM, "Nevio" notifications@github.com wrote:

You have 3rd parameter that can help you with that :)

https://github.com/0x19/goesl/blob/master/connection.go#L61

From http://wiki.freeswitch.org/wiki/Event_Socket_Outbound

Examples Here are examples of how to use it in the dialplan.

Note about async mode If you are using async, you need to pay attention to potential race condition. The commands you send may not execute in sequential order. You may force the command to wait: sendmsg call-command: set execute-app-name: foo=bar\n\n event-lock:true

— Reply to this email directly or view it on GitHub https://github.com/0x19/goesl/issues/2#issuecomment-142270712.

[0x19]

Hmm ok so if I am aware correctly you should be able to do this without any issues.

However, I gotta admit I have no clear image on what your code looks alike or what you wish to accomplish so I may be saying things you already know.

if sm, err := conn.Execute("playback", "file_one.wav", true); err != nil {
    Error("Got error while executing playback: %s", err)
    break
} else {
    Debug("Playback Message: %s", sm)
}

// Do some logic here

if sm, err := conn.Execute("playback", "file_two.wav", true); err != nil {
    Error("Got error while executing playback: %s", err)
    break
} else {
    Debug("Playback Message: %s", sm)
}

// Do some additional logic here

// Hangup and do not wait
if hm, err := conn.ExecuteHangup(cUUID, "", false); err != nil {
    Error("Got error while executing hangup: %s", err)
    break
} else {
    Debug("Hangup Message: %s", hm)
}

[MehSha]

I appreciate your very help and passion, first a bit of context, My main interest is writing software that controls a phone call, something like advanced IVR. in this applications, server ask us what to do next.so we want to execute one command and after that decide on what to do next. so we want control, and everything switch does should be in sync with our code. yes this code works, and it send commands to freeswitch and ask it to execute them sequentially. but your code runs in few microseconds and it takes many seconds (length of you files) to finish playing the files. what if you want to run play_and_get_digits and based on the input you get, do diff rent things? you should wait for command to complete and get result (many seconds), THEN act based on input. i mean after you send playback command your go app should wait for it to actually finish, then go to next line. at least IVR and call control use case needs this. we have been working with exactly this kind of framework in node.js (an internal framework based on github.com/englercj/node-esl) but after my migration to go, we need a framework for having this.

anyway, if you fix the issue #1 I will fix event dispatching to calls in my code base and finish the job, then I will share it, if it look worthy. if you are really interested i can share it with you in this current immature state. regards

[0x19]

@MehSha sorry for late reply on this. Basically I've went ahead, thought about some stuff and I can say that I'd like to rewrite this goesl pretty much so instead of fixing EOF, i'll be doing some changes in 2.0 release. Bringing this goesl more towards micro service than anything else.