Careful testing is crucial for stability before launching new SIP Access Device models
The Product Definition must be baked into the Test Plan used to approve the device, & new software for it
Customer Technical Support teams need extensive early access to devices before they are deployed

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.

Planning the Launch

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.

Avoiding Device Management Disasters

You've known about the SIP device disasters:

...when your Support Staff got calls from customers using the Yealink T-58V phone before they had ever heard of it
...and when the Engineering team had a week to roll out video calling on all the Polycom VVX phones, because customers were buying cameras
...or when the CEO of your company got the latest Mitel 6869 phone, and read that the phone could show him his company directory in Microsoft Exchange, but then it didn't work.
...and who could forget when you upgraded 1000 phones to discover the new firmware required a different file format?

BroadWorks for Device Management?

BroadWorks provides some mature tools for managing new device types, including some important key features:

The BroadWorks system owner operator can add a new device type at any time, without BroadSoft's assistance.
BroadWorks records many key SIP parameters of the device type.
BroadWorks stores the files like software and images, for delivery to the device.
BroadWorks automatically generates configuration files as the device user's changes are made
BroadWorks system owners can define custom tags to handle new features and situations. Example: Most phones don't support Apple Facetime, but if you have one phone with a FaceTime gateway, you can define "%FACETIME_GATEWAY%" as a custom tag in BroadWorks. Then BroadWorks can replace that tag macro with the appropriate value for each customer.
BroadWorks can deliver the files to the device with HTTP or HTTPS, confirming username/password or SSL client certificate.
BroadWorks can signal the device to download the new configuration file.

Key Milestones for Productizing a SIP Access Device

Decide: Which of the Features will you support?
Prototyping & Testing: Do the Features Work?
Management: Can you Control It?
Support: Can you help users use it?

Features: You Can't Support Them All

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:

Ordinary calling with Caller ID
"HD Voice," usually using G.722
Power over Ethernet
LLDP-MED for automatic Ethernet VLAN selection
Busy Lamp Field (BLF) / Line State Monitoring
Shared Call Appearance / Shared Lines
Programmable "Soft Keys"
Customizable Dial Plans (so the phone knows when you're done dialing)
Distinctive Ring
Video Calling
Bluetooth headset support
USB headset support
Multi-party Video Calling
Multicast Paging (where the speakerphone)
3-Way and N-Way Conferencing (where a large number of people can be conferenced together using the conference button)
Customizable Contact List
LDAP or Microsoft Active Directory or Exchange directory access
Customizable background logos
Calendar integration

...But many will try

But there are exotic features on every phone. Are you going to help your customers if they contact your help center asking about these?

Yealink Android phones can run Android Apps
Mitel phones has an XML API intended for integration with custom audio applications
GrandStream GXP21xx phones support Instant Messaging
Cisco 8800 SIP Phones support assigning a specific ringtone to a specific extension
Polycom UC phones support dual simultaneous registration to two different registrars at the same time for the same SIP account.

Practically, new phones are far too complex to support every feature. Choose the features you actually intend to fully, thoroughly support.

Prototyping and Testing: Prove Those Features Work

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".

Essential Parts of an Identity/Device Profile Type

An Identity/Device Profile Type (IDPT) is a specific model of device, such as a SIP phone.

The key parts are:

Profile: Identity/Device Profile Type (IDPT) Profile
File Templates: Identity/Device Profile Type (IDPT) Files & Authentication
Custom Tags

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.

Profile

In the IDPT Profile, you can set key settings that apply to every device of that type, such as:

What should the SIP Request URI look like?
Does the device supports RTP early media?
Can the device register?
Does it support HTTP authentication?
How does it handle Privacy headers?

Ideally, your vendor will specify these settings exactly.

Files

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.

File Template Example: BWDEVICE_%BWMACADDRESS%.cfg

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.

Sample Template: BWDEVICE_%BWMACADDRESS%.cfg

<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%"

...

BW and Custom Tags

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

%BWLINEPORT-1%, the SIP Address of Record (AoR), user portion
%BWHOST-1%, the SIP domain for the AoR
%BWEXTENSION-1%, the extension that can be dialed to reach the user within the user's organization

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.

Sample Generated Config File: BWDEVICE_0004fb2012345.cfg

<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"

...

The Process of Testing

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 is Product Definition

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.

Example Test Environment

Device Under Test, DUT: The Apple Blackhole Phone Model 1
DUT Setup:
- User built in BroadWorks as 229-316-1002
- BLF monitoring on position 1 for 229-316-1001
Lab Phone 1: Polycom VVX 500 at 229-316-1000
Lab Phone 2: Yealink at 229-316-1001
Cell Phone 1: iPhone X at 919-559-6000

Example Test Plan

Test Case ID: TC01
Feature: Call with Caller ID
Detailed Procedure: On DUT, while the handset is on hook, press the Speakerphone button, and dial 919-559-6000. Do not press "Send".
Expected Results: On the 919-559-6000 cell phone, it should ring, and you should see the caller ID 229-316-1000. Answer on the cell phone, and confirm that you get two-way audio. Hangup on the cell phone, and confirm that the call is disconnected on the DUT.
Actual Results: _______________________________________
What Did We Learn? _______________________________________
Test Pass? TRUE / FALSE
Test Case ID: TC02
Feature: Busy Lamp Field - monitoring
Detailed Procedure: On DUT, watch Busy Lamp Field Position 1. Place a call on test phone 229-316-1001 to 919-559-6000. Check Expected results, then disconnect by hanging up on 229-316-1001.
Expected Results: When you can hear ringback on the 229-316-1001 device, you should see the BLF indicator in position 1 on DUT. When the call is answered on cell phone 919-559-6000, the BLF indicator should change to the red bar on position 1 within 1 second. When you hang up on 229-316-1001, the BLF indicator on DUT should return to black within 1 second.
Actual Results: _______________________________________
What Did We Learn? _______________________________________
Test Pass? TRUE / FALSE

Management: Can You Control It?

Once you've proven that the core features work, you need to prove you can control it.

Remote Upgrade.

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.

Logging.

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.

New Device Procedures.

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.

Support: Enabling yourself to do a great job

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

Resource Library

The Complete Guide to Staff Augmentation for Voice Service Providers

Blog

Space Probes and SIP Phones: Successful Device Launches with