[asterisk-dev] func_odbc auto commit at answer time

Jaco Kroon jaco at uls.co.za
Wed Feb 24 03:36:08 CST 2021


Hi Dennis,

Thank you.  Becoming more and more nasty by the moment ...

On 2021/02/24 10:07, Dennis Buteyn wrote:
> On 2/24/21 1:01 AM, Jaco Kroon wrote:
>>
>> Hi,
>>
>> I still think the changes for forcecommit should be done for
>> func_odbc, however, after various discussions we've decided to give
>> the daemon route a shot.
>>
>> So just looking at the raw AMI event via UserEvent, this seems to
>> have a problem with quoting, for example:
>>
>> Set(ODBC_trace()=CallerID: ${CALLERID(all)})
>> UserEvent(trace,Message: CallerID: ${CALLERID(all)})
>>
>> The former in the DB ends up as:  CallerID: "name" <number>
>>
>> The quotes are missing in the AMI event:
>>
>> Message: CallerID name <number>
>>
>> Is this a bug, or am I missing some escaping that needs to happen
>> prior to passing to UserEvent?
>>
>> Kind Regards,
>> Jaco
>>
> Interesting, I couldn't find anyone having similar problems nor any
> working examples. I tried /UserEvent(trace,Message: CallerID:
> ${QUOTE(${CALLERID(all)})})/ but that becomes /AppData: trace,
> CallerID: "\"2000\" <2000>"/. I guess UserEvent() is having a bad day.
> While trying to encode the body as JSON (which also doesn't work) I
> did find the workaround below which I think is pretty close:
>
> UserEvent(trace,CallerID:{${QUOTE(${CALLERID(all)})}},Val:{${QUOTE("quoted")}})
>
> Event: UserEvent
> Privilege: user,all
> Channel: SIP/2000-00000016
> ChannelState: 6
> ChannelStateDesc: Up
> CallerIDNum: 2000
> CallerIDName: 2000
> ConnectedLineNum: <unknown>
> ConnectedLineName: <unknown>
> Language: en
> AccountCode:
> Context: sub-speakextennum
> Exten: s
> Priority: 3
> Uniqueid: 1614152491.107
> Linkedid: 1614152491.107
> UserEvent: trace
> CallerID: {"2000" <2000>}
> Val: {"quoted"}
>
> In any case, the UserEvent itself already contains the CID
> (CallerIDNum, CallerIDName) but I assume you were testing quoting
> behavior.
>
Stripped down version of what we have, plus keep in mind ODBC_trace()
logs *arbitrary* messages, so yes, things like certain SIP headers
aren't passed by default.

> There is also the alternative of listening to VarSet events. It is
> much more spammy but is more straight-forward in dialplan and works
> with arrays:
>
Nasty.  Basically I could then do a simple Set(trace=message here ...)
but as you say, I'd need to listen in on ALL VarSet events, and those
are indeed many.  Especially when listening on on 100+ asterisk
instances, or on a busy host (with 5-10 new INVITEs/s which I seriously
doubt is anywhere near the busiest hosts in the world, but busy enough).

> Another alternative would be to format the event per your own preferences:
>
> UserEvent(CallerID=${QUOTE(${CALLERID(all)})}|Val=${QUOTE("quoted")})
>
> Event: UserEvent
> ...
> UserEvent: CallerID="2000" <2000>|Val="quoted"
>
Interesting idea, yes, that may be an idea.  However, this seems to give
the exact right results:

UserEvent(trace,Level: user,Message: ${QUOTE(${CALLERID(all)})})

UserEvent can then absorb the outermost quotes that ${QUOTE()} adds, and
\" ends up going through correctly.

I've tried messages containing , in this configuration too, and it seems
to work correctly.  On the daemon side I can the default the Level: if
not specified.

Set(ODBC_trace(level)=Message goes here with ${VARS})

Still feels a lot cleaner to me compared to:

UserEvent(trace,Level: level,Message:${QUOTE(Message goes here with
${VARS})})

At least the conversion is now very much awk/sed'able.

POC daemon on AMI side didn't take too long to cook up either, thank you
for the suggestion.

May still consider making the forcecommit and async commit changes (With
forcecommit you lose the error reporting anyway, so making that async,
even by default, IMHO is acceptable).  Might not need it right now, but
IMHO it's still the right thing to do.

Thanks again.

Kind Regards,
Jaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210224/85031e50/attachment.html>


More information about the asterisk-dev mailing list