[Freeswitch-dev] BACKGROUND_JOB event
Whenever a call to a command is made using bgapi, a BACKGROUND_JOB event is sent by FreeSWITCH when the command is completed. A BACKGROUND_JOB event looks like this: -------------- cut -------------- Content-Length: 614 Content-Type: text/event-plain Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg: sofia/default/user2.comellas%40192.168.1.40%3A5061%202001 Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Length: 41 +OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut --------------
From what MikeJ told me over IRC, the body of a BACKGROUND_JOB message is actually a serialized event containing the response to the original command. The problem is that the content-type of the message is the same as that used by any normal event. This makes it difficult to have a generic parser, because we have to analyze the body of the message to determine whether we are dealing with a normal event or a BACKGROUND_JOB. The other problem I see is that the body containing the serialized event does not have a content-type of its own.
An example of a message with the above mentioned problems addressed could look like this: -------------- cut -------------- Content-Length: 643 Content-Type: text/background-response-wrapper-plain Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg: sofia/default/user2.comellas%40192.168.1.40%3A5061%202001 Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Type: api/background-response Content-Length: 41 +OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut -------------- What do you think? Is a change similar to what I propose feasible?
it's not a serialized event. it's actually the output of the command in question. The correct way to deal with it is to subscribe to the BACKGROUND_JOB event and use the Job-UUID header to match the packet to the uuid given as a response to the submission of the request. When a match exists the body of that event will be the output generated by the API call. On Mon, Apr 28, 2008 at 5:45 PM, Juan Jose Comellas <juanjo@comellas.org> wrote:
Whenever a call to a command is made using bgapi, a BACKGROUND_JOB event is sent by FreeSWITCH when the command is completed. A BACKGROUND_JOB event looks like this:
-------------- cut -------------- Content-Length: 614 Content-Type: text/event-plain
Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg: sofia/default/user2.comellas%40192.168.1.40%3A5061%202001 Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Length: 41
+OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut --------------
From what MikeJ told me over IRC, the body of a BACKGROUND_JOB message is actually a serialized event containing the response to the original command. The problem is that the content-type of the message is the same as that used by any normal event. This makes it difficult to have a generic parser, because we have to analyze the body of the message to determine whether we are dealing with a normal event or a BACKGROUND_JOB. The other problem I see is that the body containing the serialized event does not have a content-type of its own.
An example of a message with the above mentioned problems addressed could look like this:
-------------- cut -------------- Content-Length: 643 Content-Type: text/background-response-wrapper-plain
Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg: sofia/default/user2.comellas%40192.168.1.40%3A5061%202001 Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Type: api/background-response Content-Length: 41
+OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut --------------
What do you think? Is a change similar to what I propose feasible?
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
But shouldn't the content-type reflect the fact that the format of this event is different from that of other event messages? I've written a parser for mod_event_socket messages that relies on the content-type to determine how to interpret the message and here we seem to have a case where the content-type does not match its content. On Mon, Apr 28, 2008 at 8:17 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
it's not a serialized event. it's actually the output of the command in question.
The correct way to deal with it is to subscribe to the BACKGROUND_JOB event and use the Job-UUID header to match the packet to the uuid given as a response to the submission of the request. When a match exists the body of that event will be the output generated by the API call.
On Mon, Apr 28, 2008 at 5:45 PM, Juan Jose Comellas <juanjo@comellas.org> wrote:
Whenever a call to a command is made using bgapi, a BACKGROUND_JOB event is sent by FreeSWITCH when the command is completed. A BACKGROUND_JOB event looks like this:
-------------- cut -------------- Content-Length: 614 Content-Type: text/event-plain
Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg: sofia/default/user2.comellas%40192.168.1.40%3A5061%202001 Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Length: 41
+OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut --------------
From what MikeJ told me over IRC, the body of a BACKGROUND_JOB message is actually a serialized event containing the response to the original command. The problem is that the content-type of the message is the same as that used by any normal event. This makes it difficult to have a generic parser, because we have to analyze the body of the message to determine whether we are dealing with a normal event or a BACKGROUND_JOB. The other problem I see is that the body containing the serialized event does not have a content-type of its own.
An example of a message with the above mentioned problems addressed could look like this:
-------------- cut -------------- Content-Length: 643 Content-Type: text/background-response-wrapper-plain
Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg: sofia/default/user2.comellas%40192.168.1.40%3A5061%202001 Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Type: api/background-response Content-Length: 41
+OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut --------------
What do you think? Is a change similar to what I propose feasible?
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
The format is not different. Any event may have a body which is indicated by the presence of a Content-Length header. Most events do not have a body but some do, such as the MESSAGE_WAITING event which contains the protocol specific MWI data. Also the MESSAGE event contains the composed text of the message much like an email. A client should do the framing of the socket by reading headers until 2 CR are encountered and all the bytes up to that point will be a list of name: value pairs one line each. (Any multiline header data is url encoded so it still appears as 1 line on the socket) If a Content-Length header is encountered you then read exactly that many bytes from the socket. Note since this is TCP this may take more than one read so if you are supposed to read 200 bytes and the next read only returns 50 you must continue to read another 150 and so on until you have read 200 bytes or the socket has an error. Once you have read all the bytes in the content length the next packet will start on the subsequent byte. The BACKGROUND_JOB event is the same as any other event as far as the protocol is concerned. It contains a body which stores the output of the command you executed. That is the only real difference and that difference is governed by the bgapi mechanism not the event socket protocol. The fact that the event contains a background job is opaque to the protocol itself. It would be a severe limitation and violation of the scope of the protocol if it were to be aware of exactly what a background job was. The point of the Content-Type is to enumerate the differences between the types of messages the protocol is aware of. You should use the Content-Type to route the event to the client library as an event at which time your code would serialize the event into some form of local hash it can then check the event_id to route it to the code that handles specific events such as BACKGROUND_JOB and when the type is BACKGROUND_JOB you then consult the Job-UUID and the body of the message. Imagine if your E-mail used the content-type to determine if your message contained a Birthday greeting from your friend Bill..... On Mon, Apr 28, 2008 at 6:37 PM, Juan Jose Comellas <juanjo@comellas.org> wrote:
But shouldn't the content-type reflect the fact that the format of this event is different from that of other event messages? I've written a parser for mod_event_socket messages that relies on the content-type to determine how to interpret the message and here we seem to have a case where the content-type does not match its content.
On Mon, Apr 28, 2008 at 8:17 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
it's not a serialized event. it's actually the output of the command in question.
The correct way to deal with it is to subscribe to the BACKGROUND_JOB event and use the Job-UUID header to match the packet to the uuid given as a response to the submission of the request. When a match exists the body of that event will be the output generated by the API call.
On Mon, Apr 28, 2008 at 5:45 PM, Juan Jose Comellas <juanjo@comellas.org
wrote:
Whenever a call to a command is made using bgapi, a BACKGROUND_JOB event is sent by FreeSWITCH when the command is completed. A BACKGROUND_JOB event looks like this:
-------------- cut -------------- Content-Length: 614 Content-Type: text/event-plain
Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg:
sofia/default/user2.comellas%40192.168.1.40%3A5061%202001
Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Length: 41
+OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut --------------
From what MikeJ told me over IRC, the body of a BACKGROUND_JOB message is actually a serialized event containing the response to the original command. The problem is that the content-type of the message is the same as that used by any normal event. This makes it difficult to have a generic parser, because we have to analyze the body of the message to determine whether we are dealing with a normal event or a BACKGROUND_JOB. The other problem I see is that the body containing the serialized event does not have a content-type of its own.
An example of a message with the above mentioned problems addressed could look like this:
-------------- cut -------------- Content-Length: 643 Content-Type: text/background-response-wrapper-plain
Job-UUID: d19f2410-1548-11dd-9eeb-0d886880e312 Job-Command: originate Job-Command-Arg: sofia/default/user2.comellas%40192.168.1.40%3A5061%202001 Event-Name: BACKGROUND_JOB Core-UUID: f17f3284-1543-11dd-9eeb-0d886880e312 FreeSWITCH-Hostname: comellas FreeSWITCH-IPv4: 192.168.1.38 FreeSWITCH-IPv6: 127.0.0.1 Event-Date-Local: 2008-04-28%2014%3A30%3A47 Event-Date-GMT: Mon,%2028%20Apr%202008%2017%3A30%3A47%20GMT Event-Date-timestamp: 1209403847575107 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 602 Content-Type: api/background-response Content-Length: 41
+OK d19f45e4-1548-11dd-9eeb-0d886880e312 -------------- cut --------------
What do you think? Is a change similar to what I propose feasible?
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (2)
-
Anthony Minessale
-
Juan Jose Comellas