I think the basic idea is to provide PBX routing like functionality.. Ultimately, it would have:<div>1. Extension Mapped to Login (login used for register)</div><div>2. Extensions within the same group are dialable</div><div>
3. Can&#39;t dial extension to extension if groups aren&#39;t the same</div><div>4. Naturally, extension numbers can be duplicated as long as group id differs</div><div>5. Full phone number (DID) mapped to Login</div><div>
6. DIDs *can* be dialed if groups differ *with module parameter flag* (ie allow_intergroup_did_dial=1), in other words, it should be an option to hide the DID so that direct dialing between customers isn&#39;t allowed and instead must traverse LCR.</div>
<div><br></div><div>I kind of imagine that upon&nbsp;receiving&nbsp;an INVITE, we&#39;d lookup the group id based on an avp. Then pass that to a new fancy lookup() function ie: lookup($avp(s:groupid)) &nbsp;which would return the registered URI for that did/exten. I do think it&#39;s necessary to distinguish if a DID or an Extension is being dialed for many reasons:</div>
<div>1. Caller ID Display name may be different for internal calls (will transmit extension number for example, and station name)</div><div>2. E911 ANI may be different for outbound calls</div><div>3. Transmitted ANI for regular outbound calls may want to mask station&#39;s callerid</div>
<div><br>Of course, a lot of this can be done with aliases, but I think this is a more sophisticated approach that would provide for some real&nbsp;usability&nbsp;that would result in configuration files that are much more readable.&nbsp;</div>
<div><br></div><div>That&#39;s my $0.02. I like the direction you&#39;ve gone with this. Hope you don&#39;t mind my feedback. I very much appreciate your contributions!!</div><div><br></div><div>-Brett</div><div><br><div class="gmail_quote">
On Sat, Feb 7, 2009 at 7:51 PM, Sergio Gutierrez <span dir="ltr">&lt;<a href="mailto:saguti@gmail.com">saguti@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>Hi Brett.<br><br>Thanks for your comment; the idea is interesting. I will have it present for a next release of module. <br><br>The approach of integrating into register is really interesting; anyway, I hope you find useful the module in its current stage.<br>

<br>Thanks again.<br><br>Regards.<br><br>Sergio<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Sat, Feb 7, 2009 at 8:21 PM, Brett Nemeroff <span dir="ltr">&lt;<a href="mailto:brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">This is interesting, but I wonder...<div><br></div><div>Seems like it would be more useful if this was integrated also into the register function so that dynamic clients can be grouped.&nbsp;</div>

<div><br></div><div>Said another way, seems like &quot;new_uri&quot; doesn&#39;t really make sense. It should point either a new_uri or to an already registered contact. If it was integrated into register, you&#39;d put the user into a group when they register, then the lookup function would also need to pass the group.</div>


<div><br></div><div>Maybe I&#39;m thinking about this wrong.. Good idea tho. :)</div><div>-Brett</div><div><br><br><div class="gmail_quote"><div><div></div><div>On Sat, Feb 7, 2009 at 6:04 PM, Sergio Gutierrez <span dir="ltr">&lt;<a href="mailto:saguti@gmail.com" target="_blank">saguti@gmail.com</a>&gt;</span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div></div><div>Hello to all developers and users.<br><br>I just have commited a new module to OpenSIPS which is called closeddial.<br>


<br>This module is intended to offer a functionality similar to Centrex to OpenSIPS, allowing to define groups of closed dialing, using abbreviated codes.<br>
<br>Closeddial uses a database table, where the relationship between users, their abbreviated dialing codes and their grouping through a particular attribute is stored. <br><br>An example which illustrates the idea behind module:<br>



<br>Supposing that the following is the content of closeddial table on database<br><br>User&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; closeddial_code&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; group_id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; new_uri<br>135 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; companyA &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:sip%3A123@proxy1.com" target="_blank">sip:123@proxy1.com</a><br>



357&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 01&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; companyA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:sip%3A357@proxy1.com" target="_blank">sip:357@proxy1.com</a><br>579&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 02&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; companyA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:sip%3A579@proxy1.com" target="_blank">sip:579@proxy1.com</a><br>



024&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00&nbsp; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; companyB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:sip%3A024@proxy1.com" target="_blank">sip:024@proxy1.com</a><br>246&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 01 &nbsp; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; companyB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:sip%3A246@proxy1.com" target="_blank">sip:246@proxy1.com</a><br>



468&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 02&nbsp; &nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; companyB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:sip%3A468@proxy1.com" target="_blank">sip:468@proxy1.com</a><br clear="all"><br>Users defined within group companyA can use abbreviated codes to dial to others users, instead of using full username; their abbreviated codes will not collide with codes defined for group companyB, because group_id is determined by using from username, before looking the uri to rewrite.<br>



<br>group_id value can be left to be determined by querying database, or can be passed from script, in case it be determined from other mechanism (for example, an avp loaded at register time).<br><br>I hope this module be useful in your deployments of opensips.<br>



<br>Feel free to send me any doubts or feedback about module, through users lists, or directly to my mail.<br><br>Best regards.<br><font color="#888888"><br>-- <br>Sergio Gutiérrez<br>
</font><br></div></div>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br>Sergio Gutiérrez<br>
</font></blockquote></div><br></div>