Ticket #1690 (new Feature Requests)

Opened 4 years ago

Last modified 3 months ago

Add custom contexts (as "dial contexts") to core

Reported by: gregmac Assigned to:
Priority: major Milestone: Cut Line
Component: Core Version: 2.2
Keywords: Cc:
Confirmation: Unreviewed SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description (Last modified by gregmac)

The custom contexts module #1447 functionality should be added to core.

Update: See CustomContexts for full discussion

Sub-tasks:

  • Implement TimeConditionsChange, remove time conditions from the CC module, and use the abstraction provided by the updated timeconditions module
  • Get rid of destinations in contexts by default - that behaviour should be provided by another module, or implemented differently so it's less confusing. It is a powerful feature, but goes far beyond just having "dial contexts" that users can use..

Contexts should be "dial contexts" really, so a user is assigned to a context, which controls what they are allowed to dial.

Each context can have various objects assigned to it: users, page groups, conferences, feature codes, outbound routes, etc.

With this setup, there are various scenarios made possible, for example:

  • one-way restricted calling
    • User 101, assigned to context "restricted"
    • Users 102, 103 assigned to context "default"
    • Context "default" contains 101, 102, 103, outbound-allroutes, ext-page, app-callforward, app-voicemail, ....
    • Context "restricted" contains 102, and ext-page.
    • A someone calling from 101 can only call 102 or use paging groups. They cannot call 103, make outgoing calls, or use voicemail. 102 and 103 can both call 101, as well as make outbound calls, use voicemail, etc.
  • different routes for different users
    • User 110 could be in context "main", user 112 could be in "voip"
    • the "main" context has a route that matches NXXXXXX, and dials on a local T1 line, and then a SIP provider. The "voip" context can also have a route matching NXXXXXX, but dials only on the SIP provider.
    • 110 and 112 can both dial 5551234, but 110 will use the T1, while 112 will use the SIP trunk

Change History

01/23/07 05:09:07 changed by diego_iastrubni

see also ticket:142

is it safe to close ticket:142 and leaving this one only?

02/19/07 09:16:34 changed by gregmac

  • description changed.

02/19/07 09:17:52 changed by gregmac

See also #1799 (description updated to reflect this scenario)

03/29/07 01:57:00 changed by gregmac

  • description changed.

03/30/07 05:29:41 changed by w5waf

Would these features be possible:

1) Restricted phone to be able to dial 911 2) Different MOH per context

03/30/07 05:38:09 changed by p_lindheimer

w5waf:

1) yes 2) depends on what you mean, you should further define it. Not related to dial contexts, current 2.3 MoH abilities are: a) set MoH class for inbound calls based on the DID they came in on; b) set MoH class for outbound calls based on the outboud route used for a call (e.g. call goes out a 'Japan' route, you can set the MoH class to 'Japan_Music' for example.

12/17/07 00:40:27 changed by Blackdog

I've been looking at doing something similar. My objective is to add a 'Groups' function Where you create one or more groups and put extensions and trunks into them.

Extensions can be in multiple groups, as can Trunks.

This means that when a person picks up a phone and dials, the outbound routing will skip all outbound trunks which do not share a group with this particular extension. The default logic would assume all extensions and all trunks share a global 'default' group if no other groups have been created...

I've mostly sorted out how it will be implemented, but If something like this already exists, I'd like to avoid re-inventing the wheel if possible.

06/10/10 14:37:03 changed by naftali5

(In [9817]) re #1447, re #1690 - simple changes, just enough to make CustomContexts work with 2.8

06/11/10 07:45:19 changed by mbrevda

  • confirmation set to Unreviewed.

(In [9818]) re: #1447, #1690; reverting changes to make way for #4335

06/11/10 07:46:57 changed by mbrevda

(In [9819]) re #1447, #1690; reverting r9817 to make way for #4335