Enterprise Alert provides so many great alert notification and remote incident managed scenarios. The ones that I personally like most are based on voice call notifications or conferences. To get these scenarios to work Enterprise Alert needs to be connected to a VoIP system in order to be able to call phones and be called by users. In this blog article, I’d therefore like to document the requirements and capabilities for Enterprise Alert when implementing voice calls.

Basics

Enterprise Alert does VoIP i.e. it does standard Voice over IP. What this means is described in the protocols section, but I thought it makes sense to clarify that we don’t connect to PBX systems with a phone card in the server. We have focused on VoIP as this IP-based technology simplifies virtualization and is more adequate in the cloud world.

However, if you really want to go for analog or ISDN-based phone calls, you need to think about how Enterprise Alert can talk VoIP with the corresponding hardware card. In case of Dialogic Media Boards, there used to be a VoIP-based endpoint that they called Dialogic SIP Control. It came with the Dialogic driver suite and provided a great VoIP Server for Enterprise Alert. That meant that Enterprise Alert talked VoIP with the Dialogic SIP Control on the host where Enterprise Alert is running and the media board is located. I’m not sure if Dialogic still supports SIP Control or how it is licensed.

VoIP Protocols

Enterprise Alert supports the following VoIP protocols.

Signaling

1. SIP Protocol as defined in RFC 3261
2. Session description according to SDP as defined in RFC 4566
3. Transport protocol can either be TCP/IP or UDP as suggested in RFC 3261
4. Enterprise Alert supports “Early Offer” only, meaning that each INVITE MUST contain the SDP PDU in the INVITE body for incoming calls to EA. Early Offer can be activated in almost all VoIP Servers.
5. Enterprise Alert can connect to the VoIP system either as Trunk or as a Phone endpoint. Connecting Enterprise Alert as Phone Endpoint is not recommended, simply because Enterprise Alert itself is more a phone server that manages calls on behalf of others i.e. Enterprise Alert is not a user in the calls and serves more as a gateway that connects people to each other. When it is connected as a phone endpoint it sends SIP REGISTER requests in the interval that the server specifies, which adds unnecessary network overhead. When connected as trunk there are no REGISTER requests that are sent. The IP to which the VoIP server sends incoming phone calls for Enterprise Alert is often configured statically in the VoIP Server.
6. When Enterprise Alert connects to the VoIP server it can authenticate via Digest Authentication (from HTTP) with MD5 hashes.
7. Enterprise Alert does support SIPS, which means it does support encrypted SIP.
8. Call forwarding (e.g. for the “Call the on-call person” scenario) can be done via “Attended Call Transfer” (http://www.in2eps.com/fo-sip/tk-fo-sip-service-05.html) if supported by the VoIP Server. If Attended Call Transfer is not supported, Enterprise Alert can stay in the line between both people and mix their audio packets together so that they can hear each other. This option would always be available with Enterprise Alert, but it also adds more network overhead. If you have the option, we recommend using Attended Call Transfer since the parties that are connected by Enterprise Alert can continue talking individually once Enterprise Alert has left the call.
9. Phone conferences are managed entirely by Enterprise Alert at the moment. This means that established conferences are not handed over to the VoIP server with SIP REFER request(s).

Audio

1. The supported audio codecs are G711 a-law or u-law as specified below:
   1. PCMU (µLaw), Sample Rate: 8000Hz, Channels:1, 8Bit/Sample
   2. PCMA (ALaw), Sample Rate: 8000Hz, Channels:1, 8Bit/Sample
      These codecs are proposed in our SDP. Other codecs are not supported.
2. Audio is encoded and transmitted with the Real-time Transport Protocol (RTP).
3. SRTP (Secure Real-time Transport Protocol) is supported by Enterprise Alert

Ports

The following VoIP related ports should be opened for Enterprise Alert in your firewalls:

1. Signaling: Open the standard VoIP port 5060 for SIP and configure that port in Enterprise Alert as “local listening address”. Otherwise Enterprise Alert will listen on a random allocated port (which can make sense when connecting as phone endpoint).
2. Audio (RTP): RTP ports are allocated dynamically by Enterprise Alert with each phone call within the configured Port range. The range is different for each VoIP channel that you create in Enterprise Alert. The first VoIP connection starts on port 25500, the second from 26000, the third from 26500 and so on. Each connection then increments the port per phone call is performs. The first call on the first VoIP channel would be done on 25500, the second call on 25502, the third on 25504 and so on.
   We recommend that you whitelist the RTP protocol in your firewall for Enterprise Alert completely as it might be difficult to allow it on a port basis.

Incoming phone calls to Enterprise Alert

Incoming phone calls to Enterprise Alert must be deployed in the VoIP system to which Enterprise Alert connects. The idea is to define phone numbers in the VoIP server that can be called to reach Enterprise Alert. The VoIP server forwards all incoming call requests (targeted to the phone numbers or extensions registered for Enterprise Alert) to the corresponding VoIP connection in the Enterprise Alert server. When you work with cloud-based VoIP gateway providers, each inbound phone number usually costs some money. However, the more phone numbers you have for Enterprise Alert the less phone menus Enterprise Alert may need to present when being called. Scenarios could be bound to a phone number directly e.g. if you want to call the on-call person of a specific team, it should be sufficient to call a specific extension or phone number to get connected via Enterprise Alert. On the other hand, if you only have one phone number for Enterprise Alert, you would need to tell Enterprise Alert which on-call person you want to get forwarded to by entering a team code on your phone’s key pad.

VoIP Servers or Cloud Gateways integrated with so far

Finally I’d like to list some VoIP systems that we have had good experiences with so far (many thanks to my colleague Hanno from the Derdack Support Team):

• Cisco Unified Call Manager 8.x or higher
• Avaya Aura Communication Manager (e.g. R016x.02.0.823.0 AVAYA-SM 6.2.4.0.624005)
• OmniPCX Enterprise Communication Server (e.g. R10.1.1 j2.603.24)
• Siemens HiPath (3000 and 4000)
• Unify OpenScape Voice
• Mitel-3300-ICP (http://edocs.mitel.com/UG/EN/NAV_33_UG_R1_EN.pdf)
• placetel (German cloud based VoIP provider: http://www.placetel.de/)
• Skype Connect (International cloud based VoIP provider: http://www.skype.com/en/features/skype-connect/)
• Virtual-Call (International cloud based VoIP provider: http://www.virtual-call.com/)