Some thoughts on improving paging and intercom to extend its abilities and ready it for provisioning (but useful prior also).

Infrastructure Tables:

Paging_Phones: this table should probably be part of DevicesTakeTwo
manuf: varchar()
model: varchar()
macro: varchar()

Paging_Macros:
macro: varchar()
pri: int()
command: varchar

Paging_Xtn_Overide
xtn: varchar() macro: varchar()

Now some context. Instead of explicit Set() commands to set the SIP header info (or equivalent), a macro is called for the phone type, or a default macro which may do several commands. Several phones may share the same method of auto-answering, so they can all point to the same macro. These macros are generated from the Paging_Macros table. So when a call is to be intercommed or paged (more to come below), it's provisioning information is checked and if present looked up in the Paging_Phones table. If not found, it is set to default. Next, the extension is looked up in teh Paging_Xtn_Overide in case it has been overridden. (or there is no provisioning info). If so this is used. (Again, note the use of astdb below which may make this unecessary). The final answer is the macro to be called to prepare this extension to be auto-answered.

gregmac: again, the device-specific stuff should be handled by DevicesTakeTwo, not the paging module - we don't want to have to release paging everytime support for a new device is added.

Now on to intercomming and the use of astdb. (And the above paging may actually want to use the astdb info as you will see next). Today you can enable or disable intercom globally. That has limitations. You also have no ability to disable paging - unless the device itself can accomplish that through DND or other means. The following astdb structure is proposed:

AMPUSER/<xtn>/autoanswer/paging: enable/disable
AMPUSER/<xtn>/autoanswer/macro: Macro to call
AMPUSER/<xtn>/autoanswer/intercom/all: enable/disable
AMPUSER/<xtn>/autoanswer/intercom/<xtn>: enable/disable

For paging:
paging enable/disable would allow you to disable the phone. Doing a forced page would ignore this. The macro information would make it easier for the dialplan (or an agi script) know how to page the phone. This may make for more simple dialplans being generated.

For intercom:
You would now have the ability to selectively allow or deny other phones to be able to intercom you, vs. all or none. A common scenario may be restricting intercoming to your personal assistant. The flow would be as follows. If ~intercom/all is enabled, check to make sure ~intercom/<xtn> is not disabled. If so, you would be selectively disabling the specific extension. Similarly, if ~intercom/all is disabled you would then check ~intercom/<xtn> to see if the calling extension is specifically allowed to intercom this phone.

It also becomes fairly easy to extend the existing feature codes that today enable/disable intercoming. If entered in the format of *54nnn or *55nnn you would be explicitly enabling/disabling nnn from intercoming you.

Once caveat - users&devices: the much of this info should probably be associated with the device as a user may have 2 different devices in users&devices mode. (I never use that mode so don't take much interest in it). This may move the 'macro' association to the device level. Issue is, today it is all at the user level.

Some more comments an notes to catch about paging (that probably conflict with what is above since I have not read it in a while).

• paging needs to include both users and devices. Probably 2 lists like today, one for users one for devices).
• probably want an agi script that takes the lists and merges them to do the page
• intercom has a potential flaw today. It sends the intercom down channel local. A user who has multiple devices, or follow-me, etc. will have everything ring which is not desired.
  • Should check the user setting and intercom should always got to the users devices. If only one device, ring the device (not through channel local - parse out the device.
  • If user has multiple devices enabled for paging, then it needs to throw them into a un-muted page call
• In the above descriptions, since users may have more than one devices, probably need an ability per device for a user to enable/disable their settings on that devices. I would say it is adequate to save all the settings in ampuser, and then have device specific disable ability.

Yet some more thoughts to capture:

• Need to add/modify paging feature code for allow/deny so there is a toggle which allows a single button to be programmed
• Modify intercom to check if line is occupied and play busy if it is, intercom should not be able to barge in
• Intercom should begin with a beep - this is both convenient and stops people from 'spying' on you and you office
• PRESENCE
  • Put hook in intercom to generate hint for each user to show their extension state (at least with fixed devices, the login/logoff process may consider dynamically updating the hints but then a mechanism needs to be implemented for reloads although that could be handled with a #exec include script. For example, user 202 who has two devices, sip/22202 & sip/23202 would have a hint as follows which can be used on a phone's speedial button to implement intercom:
    • exten => *80202,hint,sip/22202&sip/23202
  • In preparation for func_devicestate (Asterisk 1.4) which allows for dialplan controlled hint status:
    • Add hint for each page group that is turned on during a page and off when the page ends
    • Add a hint for the intercom enable/disable toggle button that would work as follows. If the toggle function were defined as *56, then the dialplan and hint for it would be as such:
      • exten => _*56.,1,Noop(Start of dialplan)
      • exten => *56202,hint,Custom:intercom_dnd_202
      • User 202 porgrams in *56202 into a speeddial and the dialplan sets the led hint to reflect the state of the speeddial (will have to see if/how asterisk maintains such state across reloads/reboots - probably going to start to need a daemon or something to do bookkeeping upon reloads or restarts.)
• #1926 relevant ticket
  • we need to add configuration information on each extension to indicate if it allows paging and/or intercom to barge in on a call, since some phones are allowing this behavior although it may or may not be desirable for a user so they need to be able to disable it and have the system block attempts.

Page Macro

Method to determine what the phone type is on the fly and set correct ALERT_INFO in page/intercom macro:

[intercom]


exten => _*81.,1,Set(dialnumber=${EXTEN:3})
exten => _*81.,n,Set(user-intercom=${DB(AMPUSER/${dialnumber}/intercom)})
exten => _*81.,n,GotoIf($["${user-intercom}" = "disabled" ]?nointercom)
exten => _*81.,n,Gosub(getalertinfo)
exten => _*81.,n,Set(__SIPADDHEADER=Call-Info: \;answer-after=0)
exten => _*81.,n,Set(__ALERT_INFO=${ALERTINFO})
exten => _*81.,n,Set(__SIP_URI_OPTIONS=intercom=true)
exten => _*81.,n,Dial(Local/${dialnumber}@from-internal/n,)
exten => _*81.,n,Busy(20)
exten => _*81.,n,Macro(hangupcall,)
exten => _*81.,n(nointercom),Noop(Intercom disallowed by ${dialnumber})
exten => _*81.,n,Playback(intercom&for&extension)
exten => _*81.,n,SayDigits(${dialnumber})
exten => _*81.,n,Playback(is&disabled)
exten => _*81.,n,Congestion(20)



exten => _*81.,n(getalertinfo),Set(phone=${SIPPEER(${dialnumber}:useragent)})
exten => _*81.,n,Set(ALERTINFO==Ring Answer) ;if cant match returns "Ring Answer"
exten => _*81.,n,ExecIf($[${phone:0:4} = Poly]|Set|ALERTINFO=Intercom) ;match Polycom 
exten => _*81.,n,ExecIf($[${phone:0:4} = Link]|Set|ALERTINFO=Ring Answer) ;match Lynksys
exten => _*81.,n,Return

I like the concept of checking what type of phone it is based on the useragent. However - there seems to be such a diverse range of useragents which include firmware version, etc. You can truncate part of it however it seems like it may be a bit error prone. Here is an example of what a few phones/ATAs return to show the diversity:

PolycomSoundPointIP-SPIP_601-UA/1.6.5.0043
Sipura/SPA2002-3.1.5
Mitel-5212-SIP-Phone 06.00.00.19 08000F270FD2
snom300/6.2.3
Mitel-5235-SIP-Phone
Aastra 480i Cordless

Maybe a way to handle it is to check if the device type is known already (from provisioning info in the future), if not go through a method like this and barring that, set a default value. Note that other fields like Call-Info can also very by phone.