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]> 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]> 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]>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] <sip%[email protected]> >>> 357 01 companyA >>> sip:[email protected] <sip%[email protected]> >>> 579 02 companyA >>> sip:[email protected] <sip%[email protected]> >>> 024 00 companyB >>> sip:[email protected] <sip%[email protected]> >>> 246 01 companyB >>> sip:[email protected] <sip%[email protected]> >>> 468 02 companyB >>> 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. >>> >>> -- >>> Sergio Gutiérrez >>> >>> _______________________________________________ >>> 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
