UPnP Telephony DCP–One step towards easy-to-implement IP telephony

Another step towards easily-configurable IP telephony systems has been taken with the UPnP Forum just releasing the UPnP Telephony Device Control Protocol this week. Here, this provides the management of telephone-related devices that are connected across a small network in a heterogenous manner. This involves the ability for the devices to make or take phone calls, be notified of incoming calls, send and receive text and multimedia messages as well as updating local user-presence status.

It is also intended to be service agnostic so as to cater for phone services based on IP-Telephony (VoIP), cellular wireless or classic landline (ISDN or Plain Old Telephony Service) technology; as well as being device form-factor agnostic.

As with the whole of the UPnP ecosystem, this DCP provides increased room for innovation due to a logical “building-block” approach in designing these systems.

Logical Devices

Telephony Client

A UPnP Telephony Client is a device that is used by the end-user to interact with the caller at the other end of the line. A multi-handset phone system would have these devices referred to as an “extension”. This could be a device like a VoIP handset, a “softphone” program run on a computer, a TV or set-top box with IP-based video speakerphone function or a “legacy-handset-bridge” like an analogue telephone adaptor or DECT base station.

The UPnP Telephony system allows different clients to be media-specific, thus allowing for situations like an electronic picture frame that has a Webcam to become a videophone adaptor with the voice part of a videocall placed using this device being hosted through a regular VoIP handset.

Telephony Server

A UPnP Telephony Server device represents anything that can provide a telephone service to the local IP-based network. This can be in the form of a 3G mobile phone connected to the home network via WiFi, a regular telephone that has integrated PSTN/ISDN – IP bridge functionality, but would typically be in the form of a device that works as an “IP-PBX” with VoIP lines and servicing VoIP handsets.

A physical device can have multiple logical “Telephony Server” devices, with one for each “service” that calls come in on. It doesn’t matter whether the calls come in via VoIP or a classic telephony service like a 3G mobile service or the “Plain Old Telephone Service”.  This can cater for the VoIP-enabled router or “IP-PBX” that can handle a few VoIP services as well as a “Plain Old Telephone Service” line; or a mobile phone or “MiFi” router that "front-ends” its 3G/GSM telephony service to the network.

Telephony Control Point

This is effectively the “control surface” for a UPnP Telephony system and can be integrated with a Telephony Client or Telephony Server or be its own device. Typically this would be the buttons and display on a phone but could be a device with its own display or a “widget application” on a computer showing up the incoming call details or incoming text / multimedia messages.

Functionality provided

This device class manages the creation, management and conclusion of a voice or video call between UPnP-compliant telephony “hub” devices and endpoint devices.

The technology allows for a call to be set up using multiple devices on the local side. A good example of this would be to instigate a videocall with the video display appearing on a videophone-enabled TV with integrated Webcam and the conversation sound coming through the cordless handset. Of course, it will do the usual call-management features like call transfer are able to be performed across a UPnP Telephony-based phone setup.

As well, there is support for a common address book that is based on vCard standards as well as the management of answering-machine / voice-mail setups in these systems. Of course, a UPnP-based IP telephone system can support sending and receiving of text or multimedia messages. This would mean that, for example, incoming messages could appear on devices like networked TVs or a Wi-Fi-based cordless IP phone could send messages through VoIP SMS services or “landline-SMS” services provided on PSTN or ISDN services.

Issues that need to be looked at

Establishment of IP-telephony services

An issue that needs to be looked at is the setup and management of IP-based telephony services. Here, this may include the addition of a new service or the establishment and modification of outbound and inbound call-management profiles associated with multiple phone services.

This may involve the use of predefined call classes like “local” or “international” with the ability to determine which service is used for a particular class. Similarly, there could be the use of “default” outbound dialling plans such as “VoIP for all calls except emergency or service calls”. As far as the small-business owner is concerned, this issue may encompass the creation of IP-based “tie lines” between business locations or the creation of “virtual extensions” which are phone numbers dialled as if one is calling an extension within a business phone setup.

The solution that can be used to answer the problem regarding establishment of such services could be in the form of a standard “service manifest” file. This could be an XML file that is prepared by the ITSP (Internet Telephony Service Provider) with all of the parameters associated with an IP telephony service including SIP parameters and default call-management plans for that service. The service’s customer would upload the file to their VoIP gateway through a client-side application or the gateway’s Web interface and simply enable the service.

Inter-extension calling

In the same case, another issue that may need to be looked at is the ability for a UPnP-based telephony system to support the placing of calls between Telephony Client devices, as required of a business phone setup.

This question could be answered through the use of a virtual Telephony Server in a gateway device that represents and handles the internal calls. This could have the internal phone book which is simply a user-friendly list of Telephony Client devices on the system as well as handling that traffic.


Now that the UPnP Telephony DCP has been determined as a standard, it now requires industry to set about the task of implementing it in as many IP-Telephony devices and software programs as possible.

This could be made feasible through this standard being part of one or more logo-compliance programs like how the UPnP AV DCPs have become mandatory for devices that are DLNA-compliant or the UPnP Internet Gateway Device standard has become mandatory for various standards encompassing Internet modems and routers.

It can also open up opportunities of innovation for any device that offers some sort of telephony function while facing a small IP network; or any computer program that works as a bridge to a telephony service like Skype or as a telephony endpoint like a “softphone”.

Making VoIP easier for the home, SOHO and small-business user

A new networking trend that is approaching the small network user is VoIP (Voice Ovr IP). It will typically include IP-based videoconferencing and offer such benefits as free or very low-cost calls, “local number anywhere” and wideband (FM-grade) telephony. Businesses of all scales are moving away from the classic PABX or key system which has its own wiring infrastructure and moving towards an IP-based business telephony system which uses existing local-area-network infrastructure. For them it also reduces the need to rent extra telephone lines for such requirements as inter-location “tie lines”.

The main problem with current VoIP setups is that they are hard to configure. Typically, you have to determine the network configuration for your VoIP service provider and work out particular “dialling plans” such as whether to use VoIP or standard telephone to make a particular call. The other factor you have to work out is which number your VoIP handset rings to. Most of these setups involve awkward interfaces and terms, including remembering certain parameters to be set across multiple devices. In some situations, this kind of work still needs one who has technical knowledge of all things to do with business telephony.

A lot of VoIP service providers have responded to this issue by selling pre-configured VoIP hardware that is locked down to their services. This situation ends up with the hardware being useless if you decide to move to a better deal offered by a competing service provider or decide to expand and evolve the system.

One way of improving the setup is to provide service-plan data packages that can be uploaded to VoIP hardware. This can be useful when it comes to signing up to a new service provider or upscaling the existing VoIP service. Another improvement that can exist could be preset outbound dial plans such as “VoIP for calls other than local & emergency / service”, “VoIP for calls other than emergency / service” or pre-defined “VoIP tie-lines”. These can be selected through a wizard-style interface.

The inbound call plan would be set up through a service-extension map for “direct inward dial” or simple “one-click” options for basic “all-call” setups.

As far as the provisioning of new VoIP telephone extensions goes, VoIP systems should consider use of UPnP and similar IP-based technologies for this purpose. The other issue that also needs to be considered is a standard data package for supplying the extensions (VoIP handsets or analogue telephone adaptors) with the necessary data. This avoids the requiement to have a system that can only work with telephones from a few vendors and can allow innovation in this field. It is more of concern as far as WiFi-based VoIP handsets, including “fixed-mobile convergent” mobile phones, are concerned.

The data packages would be an XML-based configuration file that contains information about SIP / STUN provider details, handset identity details and outbound / inbound dial plans.

Once measures are taken to make VoIP telephony easier to deploy, this can lead to system owners being able to have home and business telephony their way.