Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 29341-20-11: UPnP Telephony Call Service
ISO/IEC 29341-20-11 — Telephony — Call Service Standard for Universal Plug and Play
Introduction to UPnP Telephony Call Service
The ISO/IEC 29341-20-11 standard defines the UPnP Telephony Call service, a core component of the UPnP Telephony architecture that enables call control functionalities across home and small business networks. This service specification provides a standardized interface for initiating, managing, and terminating telephony calls over IP networks, supporting both audio and video communication sessions. It abstracts the underlying telephony infrastructure, allowing diverse devices such as IP phones, softphones, media servers, and home gateways to interoperate seamlessly in a multi-vendor environment.
The UPnP Telephony Call service leverages the standard UPnP Device Architecture (UDA) defined in ISO/IEC 29341-1, ensuring consistent discovery, description, and eventing mechanisms across all UPnP-enabled telephony devices.
Service Architecture and State Variables
The Call service exposes a set of state variables that reflect the current status of telephony calls within the network. Key state variables include CallState (idle, dialing, ringing, connected, held, conferenced, etc.), ActiveCallList which enumerates all currently active calls with unique identifiers, and LineStatus indicating the availability of telephony lines. Each call session is uniquely identified by a CallID, and the service maintains a call history log for diagnostic and billing purposes.
The state machine governing call transitions follows the ITU-T Q.931 recommendation adapted for packet-switched networks. Transitions between states are triggered by actions such as Dial, Answer, Hangup, Hold, Retrieve, Conference, and Transfer, each mapped to corresponding UPnP actions with well-defined input and output arguments.
Implementers must handle edge cases such as concurrent incoming calls, call waiting indications, and network-initiated disconnections. The state machine must correctly transition to idle when a call is terminated by either party or due to network failure.
Key Actions and Use Cases
| Action | Description | Required Arguments |
|---|---|---|
| Dial | Initiate an outgoing call to a specified URI | CallTargetURI, PreferredMedia |
| Answer | Accept an incoming call session | CallID |
| Hangup | Terminate an active call session | CallID |
| Hold | Place an active call on hold | CallID |
| Conference | Merge multiple calls into a conference session | CallIDList |
| Transfer | Transfer a call to another URI | CallID, TargetURI |
| SendDTMF | Transmit DTMF tones during a call | CallID, Digits |
Typical use cases include basic peer-to-peer calling, three-way conferencing, call forwarding, and integration with media servers for voicemail and auto-attendant services. The service also supports supplementary services such as caller ID presentation, call waiting notification, and anonymous call rejection.
The Call service’s eventing mechanism enables real-time UI updates on control points. When a call state changes, the service sends event notifications to all subscribed control points, allowing applications to display ringing alerts, call duration timers, and line status indicators without polling.
Engineering Design Insights
When implementing the UPnP Telephony Call service, special attention must be paid to synchronization between the UPnP state machine and the underlying SIP or H.323 protocol stack. The service acts as an abstraction layer — mapping UPnP actions to SIP methods (e.g., Dial → INVITE, Hangup → BYE, Hold → re-INVITE with hold SDP). Latency introduced by the UPnP control path must be minimized to avoid perceptible delays in call setup.
Security considerations include authentication of call control requests, encryption of signaling messages via TLS, and validation of URI parameters to prevent toll fraud and unauthorized call placement. Manufacturers should also implement rate limiting on the Dial action to mitigate abuse in automated dialing scenarios.
Failure to properly implement the call state machine can lead to resource leaks — orphaned media channels, stuck state indicators on control points, and billing discrepancies. Always implement timeout-based cleanup for half-open calls and validate state transitions rigorously against the state diagram defined in the standard.
Frequently Asked Questions
Q: Can the UPnP Call service support video calls?
A: Yes. The PreferredMedia argument allows specifying audio-only or audio-video media profiles. The service interoperates with media receivers that support the UPnP AV architecture for video rendering.
A: Yes. The PreferredMedia argument allows specifying audio-only or audio-video media profiles. The service interoperates with media receivers that support the UPnP AV architecture for video rendering.
Q: How many concurrent calls does the service support?
A: The standard does not mandate a specific limit. The number is implementation-dependent and advertised via the MaxActiveCalls state variable. Typical residential implementations support 2–6 concurrent calls.
A: The standard does not mandate a specific limit. The number is implementation-dependent and advertised via the MaxActiveCalls state variable. Typical residential implementations support 2–6 concurrent calls.
Q: Is SIP required for the underlying signaling?
A: No. While SIP is the most common transport, the standard is agnostic to the underlying signaling protocol. Implementations may use H.323, proprietary protocols, or even analog FXO/FXS interfaces as long as the UPnP state machine behavior is preserved.
A: No. While SIP is the most common transport, the standard is agnostic to the underlying signaling protocol. Implementations may use H.323, proprietary protocols, or even analog FXO/FXS interfaces as long as the UPnP state machine behavior is preserved.
