[OpenSIPS-Users] New: Closeddial module

[Brett Nemeroff]

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 <jpyle at fidelityvoice.com> 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" <brett at nemeroff.com> 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 <saguti at gmail.com> 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 <brett at nemeroff.com> 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 <saguti at gmail.com> 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:
> 123 at proxy1.com <mailto:sip%3A123 at proxy1.com <sip%3A123 at proxy1.com>>
> 357             01                              companyA        sip:
> 357 at proxy1.com <mailto:sip%3A357 at proxy1.com <sip%3A357 at proxy1.com>>
> 579             02                              companyA        sip:
> 579 at proxy1.com <mailto:sip%3A579 at proxy1.com <sip%3A579 at proxy1.com>>
> 024             00                              companyB        sip:
> 024 at proxy1.com <mailto:sip%3A024 at proxy1.com <sip%3A024 at proxy1.com>>
> 246             01                              companyB        sip:
> 246 at proxy1.com <mailto:sip%3A246 at proxy1.com <sip%3A246 at proxy1.com>>
> 468             02                              companyB        sip:
> 468 at proxy1.com <mailto:sip%3A468 at proxy1.com <sip%3A468 at proxy1.com>>
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090209/a021d056/attachment-0001.htm