Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-27-1: UPnP Telephony Device Template — VoIP and Telephony Integration Architecture
Technical examination of the UPnP Telephony:1 device template for integrating VoIP telephony services into home and small-office networks.
Overview of the UPnP Telephony:1 Device Template
The ISO/IEC 29341-27-1 standard defines the Telephony:1 device template, which extends the UPnP framework to support telephony services over IP networks. This template enables UPnP control points to discover and interact with telephony capabilities on a home network — including making and receiving calls, managing contacts, and controlling telephony features through a standardised interface. It bridges the gap between traditional circuit-switched telephony and modern VoIP architectures by providing a vendor-independent abstraction layer for telephony functions.
The Telephony:1 device template was designed during the transition period when home gateways were beginning to integrate analogue telephone adapters (ATAs) and VoIP functionality. It allows any UPnP-capable device on the LAN — from a set-top box to a game console — to act as a telephony endpoint without requiring native SIP or H.323 protocol stacks.
The device type URN is urn:schemas-upnp-org:device:Telephony:1. The template defines a telephony server that manages call sessions, a telephony client that initiates and receives calls, and a set of auxiliary services for contact management, call history, and media control. The architecture follows the UPnP device-service model where the Telephony device acts as a composite container for multiple telephony-related services.
Service Composition and Call State Machine
The Telephony:1 template defines several embedded services, each responsible for a specific aspect of telephony functionality. The core service is the TelephonyCallController, which manages the lifecycle of call sessions, including call establishment, teardown, hold, transfer, and conference bridging.
| Service | Service ID | Required | Description |
|---|---|---|---|
| TelephonyCallController | urn:upnp-org:serviceId:TelCallController1 | Yes | Call session management (setup, teardown, hold, transfer) |
| TelephonyConfig | urn:upnp-org:serviceId:TelConfig1 | Yes | Telephony device configuration and account management |
| Phonebook | urn:upnp-org:serviceId:Phonebook1 | Optional | Contact storage and retrieval (vCard-based) |
| CallLog | urn:upnp-org:serviceId:CallLog1 | Optional | Call history recording and querying |
| MediaSink | urn:upnp-org:serviceId:MediaSink1 | Optional | Audio media playback for ringtones and announcements |
The call state machine defined by the TelephonyCallController service includes states for Idle, Dialing, Ringing, Connecting, Connected, OnHold, and Terminating. Each state transition generates a GENA event notification to subscribed control points. The service supports multiple concurrent calls through a call session identifier mechanism, enabling features such as call waiting, three-way conferencing, and call parking.
One of the key engineering challenges in implementing the Telephony:1 template is synchronising the UPnP call state with the underlying VoIP signalling protocol (typically SIP). The UPnP state machine is abstract and does not map one-to-one to SIP dialog states. For example, the UPnP “Ringing” state encompasses both the SIP INVITE proceeding and the 180 Ringing response phases. Engineers must implement a state translation layer that maps SIP events to UPnP state transitions while preserving timing accuracy for features like ring timeout handling.
Implementation Strategies and Integration Patterns
Integrating the Telephony:1 device template with existing VoIP infrastructure requires careful architectural planning. The most common deployment model embeds the UPnP Telephony device within a residential gateway that also runs a SIP user agent (UA) or an IMS (IP Multimedia Subsystem) client. In this model, the UPnP Telephony device serves as a local abstraction layer: LAN-based control points interact with it via UPnP, and it in turn communicates with the VoIP service provider via SIP or IMS protocols.
A more advanced deployment uses the Telephony:1 device as a telephony server on the LAN, with multiple control points acting as extensions. This architecture supports multi-line configurations where different phones in the home can have independent phone numbers, voicemail boxes, and call forwarding rules. The TelephonyConfig service exposes account parameters such as SIP server address, authentication credentials, and codec preferences, which can be configured centrally through the UPnP device and distributed to all registered extensions.
The Phonebook service uses the vCard 3.0 format for contact data exchange, providing interoperability with popular contact management platforms. Each contact entry is stored as a complete vCard object (XML-encoded within the UPnP SOAP response), including name, telephone numbers, email addresses, and organisational information. The service supports searching by name or phone number prefix, enabling integration with IP phone displays and caller-ID matching.
From a quality-of-service perspective, the Telephony device template can interact with the WANConnectionDevice’s QoS mechanisms to prioritise voice traffic. When a call session transitions to the Connected state, the Telephony device can request a dedicated bandwidth reservation from the WAN interface, ensuring that voice packets receive priority treatment over bulk data traffic. This integration between the Telephony and WAN device templates is one of the most powerful features of the UPnP IGD suite for Triple-Play (voice, video, data) deployments.
Security considerations for the Telephony:1 device template are particularly important given the sensitive nature of voice communications. The template exposes actions to initiate calls, access contact lists, and retrieve call logs — all of which are privacy-sensitive operations. Implementations MUST restrict UPnP Telephony control to trusted LAN interfaces and should never expose the Telephony device description or services on the WAN interface. Additional protections include rate-limiting call initiation to prevent toll fraud, requiring user confirmation for calls to premium-rate numbers, and encrypting contact data stored by the Phonebook service.
When deploying the Telephony:1 template alongside SIP trunks, configure the underlying SIP UA to support at least G.711 (PCMU/PCMA) and G.729 codecs for maximum interoperability. For internal LAN calls, consider using G.722 wideband audio (16 kHz sampling) for superior voice quality. The UPnP Telephony device should expose the available codec list via the TelephonyConfig service so that control points can negotiate the optimal codec for each call session.
Frequently Asked Questions
Q: Can the UPnP Telephony device template work with SIP-based VoIP service providers?
A: Yes. The UPnP Telephony:1 template is protocol-agnostic at the UPnP level but is most commonly implemented on top of a SIP user agent. The TelephonyConfig service stores SIP account parameters (registrar server, proxy, credentials) and the TelephonyCallController maps UPnP actions to SIP methods (INVITE, BYE, REFER, etc.). IMS-based deployments are also supported through the same abstraction layer.
A: Yes. The UPnP Telephony:1 template is protocol-agnostic at the UPnP level but is most commonly implemented on top of a SIP user agent. The TelephonyConfig service stores SIP account parameters (registrar server, proxy, credentials) and the TelephonyCallController maps UPnP actions to SIP methods (INVITE, BYE, REFER, etc.). IMS-based deployments are also supported through the same abstraction layer.
Q: How many concurrent calls does the Telephony:1 template support?
A: The template itself does not impose a limit; the number of concurrent calls depends on the underlying telephony hardware or SIP trunking capacity. Typical residential implementations support 2-6 concurrent calls. The TelephonyCallController service assigns unique call session IDs to each active call, and control points can manage each call independently.
A: The template itself does not impose a limit; the number of concurrent calls depends on the underlying telephony hardware or SIP trunking capacity. Typical residential implementations support 2-6 concurrent calls. The TelephonyCallController service assigns unique call session IDs to each active call, and control points can manage each call independently.
Q: Does the Telephony device template support video calling?
A: The base Telephony:1 template focuses on audio telephony. Video calling is not explicitly defined in the standard. However, the MediaSink and MediaSource services could potentially be extended with vendor-specific profiles to support video streams. For pure video telephony, the UPnP Audio/Video (AV) architecture is generally more appropriate.
A: The base Telephony:1 template focuses on audio telephony. Video calling is not explicitly defined in the standard. However, the MediaSink and MediaSource services could potentially be extended with vendor-specific profiles to support video streams. For pure video telephony, the UPnP Audio/Video (AV) architecture is generally more appropriate.
Q: How is emergency calling (e.g., 911/E112) handled in the UPnP Telephony template?
A: The Telephony:1 template does not define special handling for emergency calls. Emergency call behaviour is determined by the underlying VoIP service provider and the SIP UA configuration. Implementations should ensure that the SIP UA supports emergency call routing (e.g., with location information in the SIP INVITE) and that the UPnP Telephony device does not block or rate-limit emergency call attempts.
A: The Telephony:1 template does not define special handling for emergency calls. Emergency call behaviour is determined by the underlying VoIP service provider and the SIP UA configuration. Implementations should ensure that the SIP UA supports emergency call routing (e.g., with location information in the SIP INVITE) and that the UPnP Telephony device does not block or rate-limit emergency call attempts.
