[OpenSIPS-Users] New: Closeddial module
Brett Nemeroff
brett at nemeroff.com
Mon Feb 9 20:42:38 CET 2009
Sergio,Thanks for sharing your scenario with us.
I've had the same need too. ie: lots of customers who each just need 1-3
phones without any features but call in/out. So this is all very
interesting.. I hope others also find this useful.
As for the REFER, my understanding is that OpenSIPs will send the refer to
the other UAC and that UAC SHOULD try to place a call to the REFERd to URI
and redirect the call to there..
For a lot of scenarios, it may not work. for example, you probably can't
REFER your carrier, but REFERing another telephone set, will probably work.
Or at least, I'd think so...
Thanks, again,
Brett
On Mon, Feb 9, 2009 at 1:36 PM, Sergio Gutierrez <saguti at gmail.com> wrote:
> 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 <jpyle at fidelityvoice.com> 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" <brett at nemeroff.com> 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 <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 <
>> http://brett@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 <
>> http://saguti@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 <
>> http://brett@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 <
>> http://saguti@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 <http://123@proxy1.com> <mailto:sip%3A123 at proxy1.com<sip%3A123 at proxy1.com>>
>>
>> 357 01 companyA sip:
>> 357 at proxy1.com <http://357@proxy1.com> <mailto:sip%3A357 at proxy1.com<sip%3A357 at proxy1.com>>
>>
>> 579 02 companyA sip:
>> 579 at proxy1.com <http://579@proxy1.com> <mailto:sip%3A579 at proxy1.com<sip%3A579 at proxy1.com>>
>>
>> 024 00 companyB sip:
>> 024 at proxy1.com <http://024@proxy1.com> <mailto:sip%3A024 at proxy1.com<sip%3A024 at proxy1.com>>
>>
>> 246 01 companyB sip:
>> 246 at proxy1.com <http://246@proxy1.com> <mailto:sip%3A246 at proxy1.com<sip%3A246 at proxy1.com>>
>>
>> 468 02 companyB sip:
>> 468 at proxy1.com <http://468@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.
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> Sergio Gutiérrez
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090209/f0c3c190/attachment-0001.htm
More information about the Users
mailing list