<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 20, 2014 at 1:10 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">George Joseph wrote:<br>
<br>
<snip><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or separate objects from a config file perspective but implemented in<br>
pjsip_configuration with endpoint.<br>
</blockquote>
<br>
Completely separate. Mixing the two defeats the purpose of having a clear boundary.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div> </div><div>Ok, how about this...   2 new object types called "composite" and "pattern" (or whatever) implemented in a separate res_pjsip_* module</div><div><br></div><div><font size="1" face="courier new, monospace">[mytrunk]</font></div><div><font size="1" face="courier new, monospace">type = composite</font></div><div><font size="1" face="courier new, monospace">pattern = trunk</font></div><div><font face="courier new, monospace" size="1">etc...</font></div><div><br></div><div><font size="1" face="courier new, monospace">[trunk]</font></div><div><font size="1" face="courier new, monospace">type = pattern</font></div><div><font size="1" face="courier new, monospace">register = yes</font></div><div><font size="1" face="courier new, monospace">contacts = static</font></div><div><font size="1" face="courier new, monospace">outbound_auth = yes</font></div><div><font size="1" face="courier new, monospace">inbound_auth = no</font></div><div><font size="1" face="courier new, monospace">identify = yes</font></div><div><br></div></div></div></div>