VoIP Mailing List Archives

[anthony.minessale at g...]

As soon as the socket reads even one byte of input it will never send any events until it has fully parsed the input packet and replied to it. In the unlikely event of an event being delivered over the socket with perfect timing to be received as soon as you put in a command you would have to cache that event and continue reading until you got your reply. You can count on the fact that you will never get the wrong reply over the socket as it will never allow anything else to happen until it deals with the current input.

In my perl client in tree just to be safe i serialize and cache any events that may be received during the waiting for a reply to a command. Like I said all events will be stopped until you get the command reply, they are being cached in a fifo and will all come over the wire as soon as the command is completed. This allows you to execute commands where you intentionally want to block until you get the answer and in cases where you don't want that you can use the bgapi command to launch the command in a thread and have it return instantly.



On Wed, Oct 22, 2008 at 8:42 AM, Klaus Teller <klaus.teller@gmx.net (klaus.teller@gmx.net)> wrote:

[klaus.teller at gmx.net]

Hi,

I have a pretty silly question here, so please bear with me. When reading events through a socket (socket event interface), it is said that i should either wait for 2CR or if the content length was specified, i must continue reading until i got the exact number of bytes from the input stream.

Now, what happens when reading simple responses such as:

Request response: Content-Type: command/reply
Reply-Text: +OK

Is there a way to detect the end of such blocks?

The issue i have is following. Given that events are asynchronous (please correct me if i'm wrong), i need a thread which continuously read and process them as they arrive. But then, considering that not only events are sent by Freeswitch, i want to also detect different response commands properly.

Let me give an example. I send a command to Freeswitch to play a file. Right after that, i wait for the answer from Freeswitch. But just before the response, Freeswitch could send a DTMF event. If i use a dedicated reading thread, how does it identify the response that resulted from the play file command? Otherwise, if i try to synchronously wait for the result just after sending the play file command, how do i say that what i will get from Freeswitch is not just the part of an event?

Does this make any sense to you?

Thanks,
Klaus.

--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

_______________________________________________
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

[klaus.teller at gmx.net]

Thanks for the info. I was also missing that responses sent by Freeswitch are also terminated with double CR.


Quick followup question: I noticed that on the event socket interface, for any single DTMF digit pressed, Freeswitch sends two DTMF events. One with Channel-State: CS_EXCHANGE_MEDIA and the other with Channel-State:CS_EXECUTE. Is that intentional?

Cheers,
Klaus.

-------- Original-Nachricht --------