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.
Conclusion
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”.
