Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 29341-20-13: UPnP Telephony Device Service
ISO/IEC 29341-20-13 — Telephony — Device Service Standard for Universal Plug and Play
Introduction to UPnP Telephony Device Service
The ISO/IEC 29341-20-13 standard defines the UPnP Telephony Device service, which provides a device-level abstraction for telephony-capable hardware in a UPnP network. Unlike the Call and Message services that focus on specific communication functions, the Device service models the physical or virtual telephony endpoint itself — including its capabilities, line configuration, network registration status, and user interface characteristics. This service is essential for enabling consistent device discovery and management across heterogeneous telephony hardware.
The Telephony Device service acts as a container service that hosts the Call, Message, and Media services. When a UPnP control point discovers a Telephony Device, it automatically knows which telephony services are available without additional service discovery steps.
Device Data Model and Capabilities
The Device service exposes a rich data model describing the telephony endpoint. The DeviceCapabilities state variable enumerates supported features such as audio codecs (G.711, G.722, Opus), video codecs (H.264, VP8), encryption protocols (SRTP, ZRTP), and network interfaces (Ethernet, Wi-Fi, cellular). The LineConfiguration variable contains the number of available lines, each line’s registration status, and associated SIP or H.323 credentials.
The DeviceInfo variable provides manufacturer details, model identifier, firmware version, and hardware revision. For mobile devices, the service exposes battery level, signal strength, and data connection type through dedicated state variables. The UserInterface capabilities indicate supported UI features such as display resolution, touch input, keyboard layout, and audio I/O paths.
Device capability negotiation is a critical aspect. The service must truthfully advertise its supported codecs and protocols so that control points can select appropriate media parameters when initiating calls. Misrepresentation of capabilities leads to failed call setup or poor media quality.
Key Actions and Device Management
| Action | Description | Required Arguments |
|---|---|---|
| GetDeviceInfo | Retrieve complete device information and capabilities | None |
| SetLineConfiguration | Configure a telephony line (SIP credentials, proxy, etc.) | LineID, ConfigParameters |
| RegisterLine | Register a line with the telephony service provider | LineID |
| UnregisterLine | Deregister a line from the service provider | LineID |
| GetLineStatus | Query the registration and activity status of a line | LineID |
| SetRingerVolume | Adjust the ringer volume level | VolumeLevel |
| SetSpeakerVolume | Adjust the speaker output volume | VolumeLevel |
| RebootDevice | Restart the telephony device | Reason |
Device management actions are particularly important for ITSP (Internet Telephony Service Provider) integration. The RegisterLine and UnregisterLine actions allow the service to manage SIP registration lifetimes, handle re-registration before expiry, and gracefully deregister during device shutdown. The service exposes the RegistrationState per line — registered, unregistered, registering, registration failed, or expired.
The event-driven architecture of UPnP makes the Device service particularly powerful for telephony device monitoring. When a device’s registration status changes (e.g., due to network outage), the service immediately notifies all subscribed control points, enabling proactive failure response and automatic failover to backup registrars.
Engineering Design Insights
One of the most challenging aspects of implementing the Telephony Device service is managing multiple registration profiles. A single device may need to register with multiple SIP providers simultaneously — for example, a business line and a personal line. The standard supports this through the LineConfigurationList variable, which is an array of line configuration entries, each with independent registration parameters and status tracking.
Security is paramount. Line credentials stored on the device must be protected against unauthorized access. Implementations should use hardware-backed secure storage for SIP passwords and TLS client certificates. The standard recommends that line configuration actions require authentication credentials passed as action arguments, preventing unauthorized modification of telephony settings by malicious control points on the network.
Storing SIP credentials in plaintext on the device is a critical security vulnerability. Implementations must encrypt credentials at rest using device-specific keys, and should provide a mechanism for remote credential revocation in case the device is stolen. The standard strongly discourages exposing credentials in UPnP event notifications or log files.
Frequently Asked Questions
Q: Can the Device service represent a software-based softphone?
A: Yes. The device abstraction applies equally to physical hardware and software endpoints. A softphone running on a PC or smartphone can implement the Device service, exposing its audio codec capabilities and line configuration.
A: Yes. The device abstraction applies equally to physical hardware and software endpoints. A softphone running on a PC or smartphone can implement the Device service, exposing its audio codec capabilities and line configuration.
Q: How does the service indicate device readiness during startup?
A: The DeviceStatus state variable transitions through states — Initializing, Ready, Registered, and Error. Control points can subscribe to event notifications to be informed when the device is fully operational and lines are registered.
A: The DeviceStatus state variable transitions through states — Initializing, Ready, Registered, and Error. Control points can subscribe to event notifications to be informed when the device is fully operational and lines are registered.
Q: Is it possible to have multiple Device services on one UPnP network?
A: Absolutely. Each telephony-capable device on the network implements its own Device service instance. Control points enumerate all available devices and present them to the user for selection — similar to how a smartphone shows multiple available SIP accounts.
A: Absolutely. Each telephony-capable device on the network implements its own Device service instance. Control points enumerate all available devices and present them to the user for selection — similar to how a smartphone shows multiple available SIP accounts.
