[asterisk-dev] AMI and Sorcery

[Joshua Colp]

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.

> 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

> 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.

> 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.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org