[Freeswitch-users] Re- Hex values inside ESL "plain" event messages?

[Martyn Davies]

Andrew,

I just wanted to to add that I used an open library called JSMN ('jasmine')
to decode JSON messages in a "C" application.  This wasn't at all painful
to use with the Freeswitch JSON-formatted events. This is another way of
solving the problem.

Regards,
Martyn


On 26 October 2015 at 21:37, Andrew Keil <andrew.keil at visytel.com> wrote:

> Nathan,
>
> Thanks for your response.  I have since implemented a simple parser that
> converts any %xx to the ASCII character (which you are correct with my aim
> to simply make it more readable).  I have tested this and it works fine.
> So if, in a future FreeSWITCH version, no %xx characters are used inside
> the values it will just work anyway.
>
> I take your point about the newline character.
>
> Andrew
>
>
> -----Original Message-----
> From: freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Nathan
> Neulinger
> Sent: Monday, 26 October 2015 2:16 PM
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> Subject: Re: [Freeswitch-users] Re- Hex values inside ESL "plain" event
> messages?
>
> A plain message couldn't safely (for parsing purposes) include all of the
> characters that would be completely valid in json.
>
> Take a newline for example. That would simply encode to \n in the text of
> a json message, but would completely screw up the plain format one.
>
> As for the selection of which characters get encoded, that I don't have
> any info on. Below I see colons and spaces inconsistently encoded. While
> probably not critical, it seems like a relatively safe choice.
>
> Simple matter - since the plain message can't possibly cover the entire
> character set - you have to support decoding, at which point, it shouldn't
> matter which ones are encoded for anything other than human readability.
>
> -- Nathan
>
> On 10/25/2015 05:24 PM, Andrew Keil wrote:
> > To FreeSWITCH users,
> >
> > I just wanted to check if there is a reason why hex values are
> > included inside the ESL "plain" event messages, since when I use JSON
> > event messages they are correctly converted to the correct ASCII
> > character.  I would prefer to use the plain messages since it is
> > quicker for my back-end in "C" to work with, however obviously I need to
> switch the hex characters back to ASCII (which is easy I know), however I
> wondered if this is just a historic thing kept in or whether it should be
> changed to output the ASCII values?
> >
> > Any feedback will be of interest.
> >
> > For example (HEARTBEAT) from a simple TELNET session to FreeSWITCH:
> >
> > event plain HEARTBEAT
> >
> > Content-Type: command/reply
> >
> > Reply-Text: +OK event listener enabled plain
> >
> > Content-Length: 901
> >
> > Content-Type: text/event-plain
> >
> > Event-Name: HEARTBEAT
> >
> > Core-UUID: 92575721-6081-4b86-baed-c44e3bf0f3c8
> >
> > FreeSWITCH-Hostname: visytel-laptop
> >
> > FreeSWITCH-Switchname: visytel-laptop
> >
> > FreeSWITCH-IPv4: 192.168.15.13
> >
> > FreeSWITCH-IPv6: 2001%3A0%3A5ef5%3A79fd%3A2cd4%3A4228%3A876a%3Aad51
> >
> > Event-Date-Local: 2015-10-26%2009%3A09%3A44
> >
> > Event-Date-GMT: Sun,%2025%20Oct%202015%2022%3A09%3A44%20GMT
> >
> > Event-Date-Timestamp: 1445810984231200
> >
> > Event-Calling-File: switch_core.c
> >
> > Event-Calling-Function: send_heartbeat
> >
> > Event-Calling-Line-Number: 70
> >
> > Event-Sequence: 512
> >
> > Event-Info: System%20Ready
> >
> > Up-Time:
> > 0%20years,%200%20days,%200%20hours,%201%20minute,%200%20seconds,%2019%
> > 20milliseconds,%20180%20microseconds
> >
> > FreeSWITCH-Version: 1.5.15b~64bit
> >
> > Uptime-msec: 60019
> >
> > Session-Count: 0
> >
> > Max-Sessions: 1000
> >
> > Session-Per-Sec: 30
> >
> > Session-Per-Sec-Max: 0
> >
> > Session-Per-Sec-FiveMin: 0
> >
> > Session-Since-Startup: 0
> >
> > Session-Peak-Max: 0
> >
> > Session-Peak-FiveMin: 0
> >
> > Idle-CPU: 99.583980
> >
> > Regards,
> >
> > Andrew Keil
> >
> >
> >
> > ______________________________________________________________________
> > ___ Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org
> > http://www.freeswitchsolutions.com
> >
> > Official FreeSWITCH Sites
> > http://www.freeswitch.org
> > http://confluence.freeswitch.org
> > http://www.cluecon.com
> >
> > 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-use
> > rs
> > http://www.freeswitch.org
> >
>
> --
> ------------------------------------------------------------
> Nathan Neulinger                       nneul at mst.edu
> Missouri S&T Information Technology    (573) 612-1412
> System Administrator - Architect
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> 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
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20151028/350c8b52/attachment.html