[Freeswitch-users] Receive order guarantee for bgapi command replies over ESL?

Fri Feb 25 14:02:56 MSK 2011

Anthony,
thanks for that post .. that is REALLY useful to know :-)

Mauritz,
I will update the Java client to make built-in use of that
information in the next week or so. I am just heading
away for a couple of days, otherwise it would be
sooner.  I will ping the list when it is updated.

davidv

2011/2/25 Mauritz Løvgren <mauritz.lovgren at hotmail.com>:
> The ability to specify the job-uuid is just what we need!
> This simplifies the bgapi command / reply / background event mechanism we
> use.
> We are currently using the Java ESL library from David Varnes as we run
> freeswitch on various platforms (Windows, FreeBSD, Mac etc etc) and wanted
> to avoid using JNI in our Java application, but we will consider using the
> swig ESL library instead if this proves to be a better solution.
>
> I am running on the latest build now, so will test using self-made job-uuids
> (will probably use UUIDs since they are really unique :-)).
>
> Thank you for the information and keep up the great work!
>
> Mauritz
>
> -----Original Message-----
> From: Anthony Minessale
> Sent: Friday, February 25, 2011 12:54 AM
> To: FreeSWITCH Users Help
> Subject: Re: [Freeswitch-users] Receive order guarantee for bgapi command
> replies over ESL?
>
> When you send bgapi command the ok with the job-uuid will always be
> for the job you just submitted.
> When you send any command you are required to wait for the reply to
> that command, if it's bgapi you will get the job-uuid.
> The only problem you face is if you are also listening for events you
> may get an event in response to your request which you must save in a
> queue and keep reading until you get the reply to the command you
> issued.
>
> If you are using the ESL library supplied with FreeSWITCH this is all
> done for you.
>
> As for the sequence ID question, you can supply your own job-uuid
> header when you send the bgapi-command
>
> bgapi show channels
> job-uuid: 1234
>
> This was not available from the script mods when I checked so I added
> it to latest build.
> example in perl but true in all swigged langs.
>
> my $command = shift;
> my $args = join(" ", @ARGV);
>
> my $con = new ESL::ESLconnection("localhost", "8021", "ClueCon");
>
> my $e = $con->bgapi($command, $args, "my-job-id");
> print $e->serialize("json");
>
>
> returns:
>
> {
>        "Event-Name":   "SOCKET_DATA",
>        "Content-Type": "command/reply",
>        "Reply-Text":   "+OK Job-UUID: my-job-id",
>        "Job-UUID":     "my-job-id"
> }
>
>
>
>
>
>
>
>
>
> 2011/2/24 Mauritz Løvgren <mauritz.lovgren at hotmail.com>:
>> Clarification:
>>
>> Yes, the event returned from the background job is expceted to be fully
>> asynchronous and can arrive at any time in the future (independent of when
>> the bgapi commands were issued).
>> The issue is the reply from the bgapi command itself, _before_ it spawns
>> the
>> background thread.
>> If you, let's say, issue 10 bgapi commands in sequence, will the reply (OK
>> Job-UUID:.... / ERR) for each bgapi command return in the same sequence as
>> issued?
>>
>> Example:
>>
>> ESL socket outputstream (writer thread):
>> client --> bgapi status --> fs
>> client --> bgapi status --> fs
>> client --> bgapi status --> fs
>>
>> ESL socket inputstream (reader thread):
>> client <-- +OK Job-UUID:..... <-- fs
>> client <-- +OK Job-UUID:..... <-- fs
>> client <-- +OK Job-UUID:..... <-- fs
>>
>> The ESL socket outputstream and inputstream are written to and read using
>> a
>> writer and a reader thread. If we have no guarantee that the order of the
>> OK
>> replies from the bgapi commands are returned in the same order as issued,
>> we
>> will be forced to do the following:
>>
>> client --> bgapi status --> fs
>> wait for reply
>> client <-- +OK Job-UUID:..... <-- fs
>>
>> client --> bgapi status --> fs
>> wait for reply
>> client <-- +OK Job-UUID:..... <-- fs
>>
>> client --> bgapi status --> fs
>> wait for reply
>> client <-- +OK Job-UUID:..... <-- fs
>>
>> Only then could we securly map the command to the correct Job-UUID for the
>> reply.
>> But if the replies arrive in correct order we can put the issued commands
>> in
>> an ordered queue that can be processed with certainty by the socket reader
>> thread, and assign replies to the correct commands.. Did this really make
>> it
>> any clearer?? :-)
>>
>> Had there been a message sequence ID (or similar construct) there would be
>> no need to be order specific as we would always have an exact match
>> between
>> command and reply, but I don't think FS / CLI / ESL supports this at the
>> moment (or ever will... ;-)).
>>
>> - Mauritz
>>
>>
>> -----Original Message-----
>> From: Anthony Minessale
>> Sent: Friday, February 25, 2011 12:10 AM
>> To: FreeSWITCH Users Help
>> Subject: Re: [Freeswitch-users] Receive order guarantee for bgapi command
>> replies over ESL?
>>
>> bgapi commands are asynchronous that means when you send the command
>> it spawns a thread and runs in the background.
>> When its complete it will send you the event, its completely dependent
>> on how long the task takes that you asked it to run.
>> Its no different that doing 12 wgets to a website in the bg, there is
>> no telling when they will be done.
>>
>>
>>
>> 2011/2/24 Mauritz Løvgren <mauritz.lovgren at hotmail.com>:
>>> The use case is as follows;
>>>
>>> Multi-threaded Java applicaton that sends bgapi commands to several
>>> channels
>>> in parallel over the same ESL connection.
>>> (bgapi commands are serialized in order to the socket outputstream, but
>>> is
>>> there any guarantee that we will receive the OK / ERR reply for each
>>> bgapi
>>> in the correct order from the socket inputstream?)
>>>
>>> And, what about sending bgapi commands on the same socket while a
>>> ‘regular’
>>> api command is currently executing? I suspect the bgapi reply will delay
>>> until the ‘regular’ (blocking) api command is finished processing?
>>>
>>> - Mauritz
>>>
>>> From: Michael Collins
>>> Sent: Thursday, February 24, 2011 9:44 PM
>>> To: FreeSWITCH Users Help
>>> Subject: Re: [Freeswitch-users] Receive order guarantee for bgapi command
>>> replies over ESL?
>>>
>>> Just curious - what is the use case where sending a stack of bgapi's
>>> without
>>> listening for the reply is more desirable than looping through the bgapi
>>> send/reply sequence for each one? I'm no super programmer but it seems to
>>> me
>>> that blindly relying on another system to always send stuff in the exact
>>> correct order is dangerous and may cause bugs that are difficult to
>>> diagnose. Personally I would consider it a programming best practice to
>>> wait
>>> for the response of the bgapi before sending another one.
>>>
>>> I invite other socket programmers to give their input...
>>>
>>> -MC
>>>
>>> P.S - you may wish to disable the legal notice at the and of your emails
>>> when sending to a public list. (We know that some servers tag outgoing
>>> messages automatically and if that is your case we understand. Go yell at
>>> the I.T. guy! :)
>>>
>>> 2011/2/24 Mauritz Løvgren <mauritz.lovgren at hotmail.com>
>>>>
>>>> Hi,
>>>>
>>>> Are replies for bgapi commands sent back to an inbound socket connection
>>>> in the same order as the commands were sent?
>>>>
>>>> Example: sending 10 bgapi messages from client to freeswitch socket with
>>>> no delay inbetween.
>>>> Will the response for those command messages be sent back by freeswitch
>>>> in
>>>> the exact same order as their commands were received, or should one wait
>>>> for
>>>> each reply before sending a new bgapi command to be sure one gets a
>>>> reply
>>>> for the correct command?
>>>>
>>>> If there was an option of providing a UUID (or sequenceId) for the
>>>> command, it would be easier to match the reply with the request upon
>>>> receival, but this doesn’t seem to be possible with the current
>>>> implementation?
>>>>
>>>> Regards,
>>>> Mauritz Lovgren
>>>> Systems Architect
>>>> IPLink Inc.
>>>
>>>
>>>
>>> ________________________________
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at 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/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> googletalk:conf+888 at conference.freeswitch.org
> pstn:+19193869900
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>

-- 
david varnes

e: david.varnes at gmail.com
p: +61 404 925 633