Space Probes are designed to be sent far away, beyond our reach. They run software, and send back data to Home Base. If the Space Probe, dies, it may never call home, and there's not much we can do to fix them from here.
For Voice Operators, the SIP Phones, IADs, User Agents, and Soft-phones clients are a bit like Space Probes: Once you deploy them, you can't go touch them. If they never "phone home," you may be out of luck. So you have to plan well to make SIP clients work properly, before they're launched.
The Challenge. There you are, in
charge of making the amazing new Hologram SIP phone work on your platform. The Product and Marketing folks LOVE this new phone, especially the way it integrates with your clients' PCs and does video calls via Google Hangouts and Apple Facetime. And it's your job to integrate the device into your BroadSoft BroadWorks network.
You've known about the SIP device disasters:
BroadWorks provides some mature tools for managing new device types, including some important key features:
Every SIP phone comes with a bazillion features, but no one network can support them all. You have to decide which features you're going to try to support. Some of the top features are:
But there are exotic features on every phone. Are you going to help your customers if they contact your help center asking about these?
Practically, new phones are far too complex to support every feature. Choose the features you actually intend to fully, thoroughly support.
Once you've chosen your features, you can develop prototype templates so that BroadWorks can generate configuration files for that phone. In most cases, in the BroadSoft community, responsible vendors will post prototype templates with example configuration files to BroadSoft's site, Xchange. These configuration file samples can be in one of the categories, "Interoperability - CPE Kit" or "Interoperability - Configuration Guide".
An Identity/Device Profile Type (IDPT) is a specific model of device, such as a SIP phone.
The key parts are:
Once a specific device (with a specific MAC address) is created in BroadWorks you can't change its Identity/Device Profile Type (IDPT). But ECG
Alpaca can move a device to a new device type, retaining all of its custom settings, users, authentication, Shared Call Appearance Settings, and even custom files.
In the IDPT Profile, you can set key settings that apply to every device of that type, such as:
Ideally, your vendor will specify these settings exactly.
For each IDPT, BroadWorks allows you to upload any number of templates and static files. Templates can be translated by an elaborate process of search-and-replace, and are usually used for configuration files. Static files are typically firmware/software and graphic images.
An excerpt from the template BWDEVICE_%BWMACADDRESS%.cfg is shown below, for the device type "Polycom VVX 500". When a "Polycom VVX 500" phone is defined on the system, and assigned the MAC address 004fb2012345, then the file BWDEVICE_0004fb2012345.cfg would be created.
<voIpProt.SIP voIpProt.SIP.enable="1">
<voIpProt.SIP.outboundProxy
voIpProt.SIP.outboundProxy.address="%OUTBOUND_PROXY%"
voIpProt.SIP.outboundProxy.transport="%TRANSPORT%">
</voIpProt.SIP.outboundProxy>
<voIpProt.SIP.conference
voIpProt.SIP.conference.address="%CONFERENCE%"/>
</voIpProt.SIP.conference>
</voIpProt.SIP>
</voIpProt>
<call call.callsPerLineKey="24"> </call>
<reg
reg.1.displayName="%BWCLID-1%"
reg.1.address="%BWLINEPORT-1%"
reg.1.server.1.address="%BWHOST-1%"
reg.1.server.1.port=""
reg.1.server.1.transport="%TRANSPORT%"
reg.1.auth.password="%BWAUTHPASSWORD-1%"
reg.1.auth.userId="%BWAUTHUSER-1%"
reg.1.label="%BWEXTENSION-1%"
reg.1.type="%BWSHAREDLINE-1%"
reg.1.acd-agent-available="%FEATURE_ACD%"
reg.1.acd-login-logout="%FEATURE_ACD%"
reg.1.serverFeatureControl.dnd="%FEATURE_SYNC_DND%"
reg.1.serverFeatureControl.cf="%FEATURE_SYNC_CF%"
...
BroadWorks defines a large number of tags that begin with the standard tag %BW, which are defined in the BroadWorks Device Management Configuration Guide (Login Wall).
As shown in this example, the BroadWorks-standard tags begin with "%BW", including
But you can define any number of other tags, which BroadWorks can track and manage. In the example above, you see %CONFERENCE%, which BroadWorks can replace with a value you specify.
A Tag Set can be created for each IDPT, with special settings appropriate for that device type. These can be set at the system level, and then overridden at the enterprise, service provider, group, or device levels of the hierarchy.
<voIpProt.SIP voIpProt.SIP.enable="1">
<voIpProt.SIP.outboundProxy
voIpProt.SIP.outboundProxy.address="proxy.voipcarrier.co"
voIpProt.SIP.outboundProxy.transport="TLS">
</voIpProt.SIP.outboundProxy>
<voIpProt.SIP.conference
voIpProt.SIP.conference.address="conf@voipcarrier.co"/>
</voIpProt.SIP.conference>
</voIpProt.SIP>
</voIpProt>
<call call.callsPerLineKey="24"> </call>
<reg
reg.1.displayName="Frederick Brooks"
reg.1.address="9195906001"
reg.1.server.1.address="proxy.voipcarrier.co"
reg.1.server.1.port=""
reg.1.server.1.transport="TLS"
reg.1.auth.password="YouMayNeedYourSanitySomeday"
reg.1.auth.userId="AlwaysInvestInYourSanity"
reg.1.label="6001"
reg.1.type="private"
reg.1.acd-agent-available=""
reg.1.acd-login-logout=""
reg.1.serverFeatureControl.dnd="0"
reg.1.serverFeatureControl.cf="0"
...
When prototyping your new device, you adjust the configuration files to implement the features in your particular network. You do this by revising the templates, and adjusting the tag values to work in your environment.
The test plan you define is the definition of the product. If it's an important part of the product, then you must put it in the test plan.
This test plan will be the Regression Test Plan later. It should be written so that all of the tests pass at the point the product is approved.
In a Test Plan, you have a "Device Under Test" (DUT) and tell the tester precisely what steps to take, and what to expect. You have to be specific: define the specific features and settings in your BroadWorks lab.
Record the actual results so that you can review and analyze them later. The person who's doing testing, the Test Engineer, should record subtleties of behavior.
Answer the question What Did We Learn, because in each test, you're discovering something about the system.
Once you've proven that the core features work, you need to prove you can control it.
Prove you can replace the software. The simplest, naive way is to replace the firmware file, and trigger phones to reboot. This can cause an unlimited phones to retrieve the new software each time.
Instead, most operator wish to selectively upgrade a few phones at a time. You can do this with a custom tag, such as %FIRMWARE%, that specifies the filename, such as "sip-1.56.2.bin". Then you can change the tag on specific phones that should have the new version of software.
ECG
Alpaca, can be used to selectively update tags on devices within a BroadWorks platform. This is routinely used to upgrade specific devices, e.g., 1000 devices per maintenance window. Alpaca can also selectively send the command to the SIP phones to reset them, and then monitor to confirm that all phones reboot properly.
All software generates logs. A manageable SIP access device puts the logs somewhere useable. With BroadWorks, you can have the device upload its logs, and BroadWorks can retain those logs for viewing on the Profile Server.
Alternately, some operators configure devices to send logs to a central log collector via syslog.
When onboarding a new device, be sure to specify the requirements for new devices. What should happen to a new device from the manufacturer?
Some operators require that a certain URL be provisioned in the phone, e.g., https://xsp.voipcarrier.co/dms/start
But this means that a new-in-box phone cannot be sent directly to the end user, without the user's intervention in the process.
Some vendors, including Polycom and Yealink, offer a redirection service. To use these, new, or factory defaulted, phone with Internet service can reach out to the phone manufacturer to get a URL to the voice operator. For example, the phone 0004b2012345 could connect to Polycom to be told to go to https://xsp.voipcarrier.co/dms/vvx600. This works only because the voice operator has registered that MAC address with Polycom, and registered the URL.
The final step before rollout of a new device type is ensuring your Customer Support department have adequate access and experience.
Provide the Customer Support with the device to use. It's remarkably common for operators to neglect to give their support folks experience on the devices that customers have. This leads to stress and poor customer service.
Have Customer Support run through the Test Plan to be sure they understand all of the supported features and settings. Since the Test Plan encapsulates the entire product definition, this means that Customer Support will know how to do it well.
The consulting firm, ECG, offers Voice Carrier technical consulting, including the proper rollout of new devices types, and support of Voice access devices in BroadWorks and other multi-vendor environments. www.ecg.co, info@ecg.co