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]> >>>>>> 357 01 companyA >>>>>> sip:[email protected] <http://[email protected]> >>>>>> <mailto:sip%[email protected]> >>>>>> 579 02 companyA >>>>>> sip:[email protected] <http://[email protected]> >>>>>> <mailto:sip%[email protected]> >>>>>> 024 00 companyB >>>>>> sip:[email protected] <http://[email protected]> >>>>>> <mailto:sip%[email protected]> >>>>>> 246 01 companyB >>>>>> sip:[email protected] <http://[email protected]> >>>>>> <mailto:sip%[email protected]> >>>>>> 468 02 companyB >>>>>> sip:[email protected] <http://[email protected]> >>>>>> <mailto: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
