Welp, I hear what you are saying.. it makes about as much sense as doing any "users" off the platform. You won't get true B2BUA functionality, but you get to a point of being able to build a pretty scalable "pbx" without features. Alot of functionality can be done in phone sets these days. <div>
<br></div><div>Will a REFER really not work? I think that really depends on what you are REFERing.</div><div><br></div><div>I'd be interested in hearing other's opinions on this. I don't use OpenSIPs as an aggregator for telephone sets, but trunks for every implementation I've done. However, I've considered hanging phones off of it.</div>
<div><br></div><div>-Brett</div><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 9, 2009 at 12:56 PM, Jeff Pyle <span dir="ltr"><<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">Brett,<br>
<br>
Would functionality like this make sense in a proxy? I'm thinking of all the things that wouldn't work. Call transfer (REFER) comes to the front of my mind.<br>
<br>
<br>
- Jeff<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<br>
On 2/9/09 1:46 PM, "Brett Nemeroff" <<a href="http://brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>> wrote:<br>
<br>
</div></div></span></font><blockquote><div><div></div><div class="Wj3C7c"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">I think the basic idea is to provide PBX routing like functionality.. Ultimately, it would have:<br>
1. Extension Mapped to Login (login used for register)<br>
2. Extensions within the same group are dialable<br>
3. Can't dial extension to extension if groups aren't the same<br>
4. Naturally, extension numbers can be duplicated as long as group id differs<br>
5. Full phone number (DID) mapped to Login<br>
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't allowed and instead must traverse LCR.<br>
<br>
I kind of imagine that upon receiving an INVITE, we'd lookup the group id based on an avp. Then pass that to a new fancy lookup() function ie: lookup($avp(s:groupid)) which would return the registered URI for that did/exten. I do think it's necessary to distinguish if a DID or an Extension is being dialed for many reasons:<br>
1. Caller ID Display name may be different for internal calls (will transmit extension number for example, and station name)<br>
2. E911 ANI may be different for outbound calls<br>
3. Transmitted ANI for regular outbound calls may want to mask station's callerid<br>
<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 usability that would result in configuration files that are much more readable. <br>
<br>
That's my $0.02. I like the direction you've gone with this. Hope you don't mind my feedback. I very much appreciate your contributions!!<br>
<br>
-Brett<br>
<br>
On Sat, Feb 7, 2009 at 7:51 PM, Sergio Gutierrez <<a href="http://saguti@gmail.com" target="_blank">saguti@gmail.com</a>> wrote:<br>
</span></font></div></div><blockquote><div><div></div><div class="Wj3C7c"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><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<br>
<br>
<br>
On Sat, Feb 7, 2009 at 8:21 PM, Brett Nemeroff <<a href="http://brett@nemeroff.com" target="_blank">brett@nemeroff.com</a>> wrote:<br>
</span></font></div></div><blockquote><div><div></div><div class="Wj3C7c"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">This is interesting, but I wonder...<br>
<br>
Seems like it would be more useful if this was integrated also into the register function so that dynamic clients can be grouped. <br>
<br>
Said another way, seems like "new_uri" doesn't really make sense. It should point either a new_uri or to an already registered contact. If it was integrated into register, you'd put the user into a group when they register, then the lookup function would also need to pass the group.<br>
<br>
Maybe I'm thinking about this wrong.. Good idea tho. :)<br>
-Brett<br>
<br>
<br>
On Sat, Feb 7, 2009 at 6:04 PM, Sergio Gutierrez <<a href="http://saguti@gmail.com" target="_blank">saguti@gmail.com</a>> wrote:<br>
</span></font></div></div><blockquote><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><div><div></div><div class="Wj3C7c">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 closeddial_code group_id new_uri<br></div></div>
135 00 companyA sip:<a href="http://123@proxy1.com" target="_blank">123@proxy1.com</a> <<a href="mailto:sip%3A123@proxy1.com" target="_blank">mailto:sip%3A123@proxy1.com</a>> <br>
357 01 companyA sip:<a href="http://357@proxy1.com" target="_blank">357@proxy1.com</a> <<a href="mailto:sip%3A357@proxy1.com" target="_blank">mailto:sip%3A357@proxy1.com</a>> <br>
579 02 companyA sip:<a href="http://579@proxy1.com" target="_blank">579@proxy1.com</a> <<a href="mailto:sip%3A579@proxy1.com" target="_blank">mailto:sip%3A579@proxy1.com</a>> <br>
024 00 companyB sip:<a href="http://024@proxy1.com" target="_blank">024@proxy1.com</a> <<a href="mailto:sip%3A024@proxy1.com" target="_blank">mailto:sip%3A024@proxy1.com</a>> <br>
246 01 companyB sip:<a href="http://246@proxy1.com" target="_blank">246@proxy1.com</a> <<a href="mailto:sip%3A246@proxy1.com" target="_blank">mailto:sip%3A246@proxy1.com</a>> <br>
468 02 companyB sip:<a href="http://468@proxy1.com" target="_blank">468@proxy1.com</a> <<a href="mailto:sip%3A468@proxy1.com" target="_blank">mailto:sip%3A468@proxy1.com</a>> <br>
<div class="Ih2E3d">
<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>
</div></span></font></blockquote></blockquote></blockquote></blockquote>
</div>
</blockquote></div><br></div>