[OpenSIPS-Users] New: Closeddial module

Mon Feb 9 20:30:00 CET 2009

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>
>>>>>> 357             01                              companyA
>>>>>> sip:357 at proxy1.com <http://357@proxy1.com>  <mailto:sip%3A357 at proxy1.com>
>>>>>> 579             02                              companyA
>>>>>> sip:579 at proxy1.com <http://579@proxy1.com>  <mailto:sip%3A579 at proxy1.com>
>>>>>> 024             00                              companyB
>>>>>> sip:024 at proxy1.com <http://024@proxy1.com>  <mailto:sip%3A024 at proxy1.com>
>>>>>> 246             01                              companyB
>>>>>> sip:246 at proxy1.com <http://246@proxy1.com>  <mailto:sip%3A246 at proxy1.com>
>>>>>> 468             02                              companyB
>>>>>> sip:468 at proxy1.com <http://468@proxy1.com>  <mailto: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/e2f59d51/attachment.htm 