Hello to all. The module appears as a solution to a problem we faced at my company; we needed to implement something like "hosted PBX" for small companies, for which having something like an asterisk would be quite large; thus, the idea is offering PBX with limited functionalities, and focused mainly in extension grouping and closed dialing.
Our previous implementation was a little bit complicated, because we used an external LDAP directory to define the groups, and an external script called through exec_dset to perform searches; we thought that having in a module, would be quite simpler an elegant than the former implementation, besides that would simplify the provisioning of service. Regards. Sergio G. On Mon, Feb 9, 2009 at 2:30 PM, Jeff Pyle <[email protected]> wrote: > As I understand it, as a proxy it will route the REFER message just fine, > but not act on it as one would expect a softswitch to. I'd like to be more > specific but I simply don't remember. > > I also use it for trunking, and am interested in others' opinions... > > > - Jeff > > > > On 2/9/09 2:11 PM, "Brett Nemeroff" <[email protected]> wrote: > > 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. > > Will a REFER really not work? I think that really depends on what you are > REFERing. > > 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. > > -Brett > > > On Mon, Feb 9, 2009 at 12:56 PM, Jeff Pyle <[email protected]> > wrote: > > Brett, > > 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. > > > - Jeff > > > > > On 2/9/09 1:46 PM, "Brett Nemeroff" <[email protected] < > http://[email protected]> > wrote: > > I think the basic idea is to provide PBX routing like functionality.. > Ultimately, it would have: > 1. Extension Mapped to Login (login used for register) > 2. Extensions within the same group are dialable > 3. Can't dial extension to extension if groups aren't the same > 4. Naturally, extension numbers can be duplicated as long as group id > differs > 5. Full phone number (DID) mapped to Login > 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. > > 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: > 1. Caller ID Display name may be different for internal calls (will > transmit extension number for example, and station name) > 2. E911 ANI may be different for outbound calls > 3. Transmitted ANI for regular outbound calls may want to mask station's > callerid > > 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. > > 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!! > > -Brett > > On Sat, Feb 7, 2009 at 7:51 PM, Sergio Gutierrez <[email protected] < > http://[email protected]> > wrote: > > > Hi Brett. > > Thanks for your comment; the idea is interesting. I will have it present > for a next release of module. > > The approach of integrating into register is really interesting; anyway, I > hope you find useful the module in its current stage. > > Thanks again. > > Regards. > > Sergio > > > On Sat, Feb 7, 2009 at 8:21 PM, Brett Nemeroff <[email protected] < > http://[email protected]> > wrote: > > This is interesting, but I wonder... > > Seems like it would be more useful if this was integrated also into the > register function so that dynamic clients can be grouped. > > 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. > > Maybe I'm thinking about this wrong.. Good idea tho. :) > -Brett > > > On Sat, Feb 7, 2009 at 6:04 PM, Sergio Gutierrez <[email protected] < > http://[email protected]> > wrote: > > Hello to all developers and users. > > I just have commited a new module to OpenSIPS which is called closeddial. > > This module is intended to offer a functionality similar to Centrex to > OpenSIPS, allowing to define groups of closed dialing, using abbreviated > codes. > > Closeddial uses a database table, where the relationship between users, > their abbreviated dialing codes and their grouping through a particular > attribute is stored. > > An example which illustrates the idea behind module: > > Supposing that the following is the content of closeddial table on database > > User closeddial_code group_id new_uri > 135 00 companyA sip: > [email protected] <http://[email protected]> > <mailto:sip%[email protected]<sip%[email protected]>> > > 357 01 companyA sip: > [email protected] <http://[email protected]> > <mailto:sip%[email protected]<sip%[email protected]>> > > 579 02 companyA sip: > [email protected] <http://[email protected]> > <mailto:sip%[email protected]<sip%[email protected]>> > > 024 00 companyB sip: > [email protected] <http://[email protected]> > <mailto:sip%[email protected]<sip%[email protected]>> > > 246 01 companyB sip: > [email protected] <http://[email protected]> > <mailto:sip%[email protected]<sip%[email protected]>> > > 468 02 companyB sip: > [email protected] <http://[email protected]> > <mailto:sip%[email protected]<sip%[email protected]>> > > > 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. > > 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). > > I hope this module be useful in your deployments of opensips. > > Feel free to send me any doubts or feedback about module, through users > lists, or directly to my mail. > > Best regards. > > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Sergio Gutiérrez
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
