<div dir="ltr">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...<div>
<br></div><div>pjsip.conf...</div><div><br></div><div><div><font face="arial, helvetica, sans-serif">[something-denver]</font></div><div><font face="arial, helvetica, sans-serif">type=aor</font></div><div><font face="arial, helvetica, sans-serif">contact=sip:<a href="http://denver1.something.net:5060">denver1.something.net:5060</a></font></div>
<div><font face="arial, helvetica, sans-serif">contact=sip:<a href="http://denver2.something.net:5060">denver2.something.net:5060</a></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">[something-denver]</font></div>
<div><font face="arial, helvetica, sans-serif">type=identify</font></div><div><font face="arial, helvetica, sans-serif">match=<a href="http://10.10.161.90/255.255.255.255">10.10.161.90/255.255.255.255</a></font></div><div>
<font face="arial, helvetica, sans-serif">match=<a href="http://10.10.159.210/255.255.255.255">10.10.159.210/255.255.255.255</a></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">AMI output...</font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Event: AorDetail</font></div><div><font face="arial, helvetica, sans-serif">ObjectType: aor</font></div><div><font face="arial, helvetica, sans-serif">ObjectName: something-denver</font></div>
<div><font face="arial, helvetica, sans-serif">Contacts: something-denver/sip:<a href="http://denver1.something.net:5060">denver1.something.net:5060</a>,something-denver/sip:<a href="http://denver2.something.net:5060">denver2.something.net:5060</a></font></div>
<div><br></div><div><font face="arial, helvetica, sans-serif">Event: IdentifyDetail</font></div><div><font face="arial, helvetica, sans-serif">ObjectType: identify</font></div><div><font face="arial, helvetica, sans-serif">ObjectName: something-denver</font></div>
<div><font face="arial, helvetica, sans-serif">Match: <a href="http://10.10.161.90/255.255.255.255,10.10.159.210/255.255.255.255">10.10.161.90/255.255.255.255,10.10.159.210/255.255.255.255</a></font></div></div><div><br></div>
<div>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.</div>
<div><br></div><div>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...</div>
<div><br></div><div>Background:</div><div><br></div><div>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.</div>
<div><br></div><div>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". :)</div>
<div><br></div><div>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.</div><div><br></div>
<div>Either way, this'll be good background info for why a patch to add 1 simple dialplan function is as complex as it is.</div><div><br></div><div>Bonus Question: Why are aors and auths specified as a single comma-separated string where contacts and matches are specified on multiple lines?</div>
<div><br></div></div>