[asterisk-dev] AMI and Sorcery

[George Joseph]

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.  Take a look at the
following abbreviated example...

pjsip.conf...

[something-denver]
type=aor
contact=sip:denver1.something.net:5060
contact=sip:denver2.something.net:5060

[something-denver]
type=identify
match=10.10.161.90/255.255.255.255
match=10.10.159.210/255.255.255.255

AMI output...

Event: AorDetail
ObjectType: aor
ObjectName: something-denver
Contacts: something-denver/sip:denver1.something.net:5060
,something-denver/sip:denver2.something.net:5060

Event: IdentifyDetail
ObjectType: identify
ObjectName: something-denver
Match: 10.10.161.90/255.255.255.255,10.10.159.210/255.255.255.255

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

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.

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". :)

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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140212/6541ce5b/attachment-0001.html>