[asterisk-dev] AMI and Sorcery

[George Joseph]

On Thu, Feb 13, 2014 at 5:38 AM, Joshua Colp <jcolp at digium.com> wrote:

> On 14-02-12 03:26 AM, George Joseph wrote:
> > In the process of creating the dialplan function AST_SORCERY (a
> > companion to AST_CONFIG) I've run into an issue with how AMI interacts
> > with sorcery particularly related to objects that can have multiple
> > occurrences of the same field like contact in aor and match in identify.
>
> <snip>
>
> >
> > Notice the inconsistency?   In the config, both contact and match are
> > singular but in the output, Contacts is plural, Match is singular.   The
> > difference comes from how the 2 objects construct the AMI event.
> >  Contact has custom code that spits out the literal "Contacts:" then the
> > list, whereas Identify uses the generic sorcery code which spits out the
> > name of the field (hence the singular) and the list.
> >
> > If the fact that one is plural and the other is singular is a bug, tell
> > me which is correct (hopefully the singular, see below) and you don't
> > have to read further unless you've got some time to kill.  If it's a
> > feature, read on...
>
> The returned name should be the name of the field, thus contact.
>

Yay!


>
> > Background:
> >
> > On Monday I started work on the AST_SORCERY dialplan function which
> > allows you to retrieve arbitrary fields from a sorcery based config like
> > pjsip.conf.  The function itself is quite simple.  Basically, it calls
> > ast_sorcery_objectset_create and iterates over the resulting
> > ast_variable list to find the field of interest.  Works great for single
> > occurrence fields but as I found out, not at all for multiple occurrence
> > fields like aor's contacts and identify's matches.  As it turns out, the
> > structure that defines a sorcery field does have a virtual function
> > member for returning multiple occurrence fields as an ast_variable list
> > but none of the objects implement it and besides, none of the
> > ast_sorcery_object_field_register functions allow you to set it.  In the
> > end, without coding object-specific logic in AST_SORCERY, there was no
> > way to retrieve the multiple occurrence fields because
> > ast_sorcery_objectset_create wasn't returning them.
>
> The multiple_fields functionality is actually exposed, just only through
> the regex support.
>
> > Well, I fixed all of that and now ast_sorcery_objectset_create can
> > return an ast_variable list with as many entries for contact and match
> > (and any others) as there are entries in the conf file.   Works
> > great...except for the AMI.   I'm told that that an AMI event can't have
> > multiple fields with the same name so multiple Contact or Match fields
> > wouldn't work.  Ok, you've always been able to register a handler that
> > spits out a single string for multiple occurrences and you can now tell
> > ast_sorcery_objectset_create which behavior you want.  Except (to bring
> > this back to the beginning), that would change the hard coded "Contacts"
> > in the event to the generically generated "Contact". :)
>
> Do you have unit tests for that? :D
>

Wrote the tests first. :)   One for the function, then updated the others.


> > So, can I remove the "s"?  Can I, Please??  Or I guess I can still use
> > the generic code and do a search and replace in the AMI output buffer
> > and add the "s" back in.
>
> I suppose the question really is... do we make this incompatible with
> the past.
>
>
Exactly.  This really wouldn't have been an issue if it was all internal
but since the AMI is an external contract...


> > Either way, this'll be good background info for why a patch to add 1
> > simple dialplan function is as complex as it is.
> >
> > Bonus Question:  Why are aors and auths specified as a single
> > comma-separated string where contacts and matches are specified on
> > multiple lines?
>
> Hilarity, that's why. Okay, not really. No immediate answer springs to
> mind.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140213/c6f4f335/attachment.html>