Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 29341-20-10: UPnP CallControl Service — Technical Specification
IEC 29341-20-10 | UPnP Telephony Service | CallControl Service Template
The CallControl Service Specification
IEC 29341-20-10 defines the CallControl service, the mandatory service template for UPnP Telephony devices. This service-level standard specifies the complete interface for managing telephony calls: initiating outgoing calls, receiving incoming calls, terminating active calls, and managing supplementary services such as hold, transfer, ad-hoc conferencing, and call park. The CallControl service is designed around a call-state machine model, where each call transitions through well-defined states driven by SOAP actions from control points and asynchronous events from the telephony network.
When implementing the CallControl service, treat the
CallID as an opaque handle. The service should generate globally unique call identifiers (e.g., UUID-based) for each call session, independent of any provider-specific identifiers, to ensure unambiguous tracking across multi-provider telephony environments.Call State Machine and Actions
The CallControl service models each call as an instance of a state machine with the following states: IDLE (no call), DIALLING (outgoing call being established), ALERTING (remote party is being alerted), CONNECTED (call is active), HELD (call is on hold), and TERMINATED (call has ended). The service exposes actions that trigger state transitions: Call (IDLE to DIALLING), Answer (ALERTING to CONNECTED), Hangup (any state to TERMINATED), Hold (CONNECTED to HELD), Unhold (HELD to CONNECTED), Transfer (CONNECTED to CONNECTED for the transfer target), and Conference (multiple CONNECTED calls into a single conference bridge).
| Action | From State | To State | Description |
|---|---|---|---|
| Call | IDLE | DIALLING | Initiate an outgoing call to the specified URI |
| Answer | ALERTING | CONNECTED | Accept an incoming call |
| Hangup | Any | TERMINATED | End the call |
| Hold | CONNECTED | HELD | Place the call on hold |
| Unhold | HELD | CONNECTED | Resume a held call |
| Transfer | CONNECTED | CONNECTED | Transfer call to another party |
The
Conference action requires special attention to media mixing. The CallControl service does not provide media processing capabilities — it relies on external media mixers or telephony infrastructure to handle audio mixing. The service’s responsibility is limited to signalling: inviting participants into the conference and tracking their participation states.Eventing and State Notifications
The CallControl service uses GENA to push state changes to subscribed control points in real time. The key evented state variables are CallState (maps to the current state of the primary call), CallID (identifies the call instance associated with the current state), CallerID (the calling party’s identifier), CalleeID (the called party’s identifier), and LineStatus (summary status of the telephony line: idle, active, ringing). The event payload uses the LastChange XML structure, enabling batch updates when multiple state variables change simultaneously — for instance, when a call connects, CallState, CallID, and LineStatus all transition together.
Implement event rate-limiting in the CallControl service to prevent event storms during rapid call state changes (e.g.,
DIALLING → ALERTING → CONNECTED transitions that occur within milliseconds of each other). Buffer short-interval state changes and emit a single aggregated LastChange event with the final state to reduce network overhead.The
CallerID state variable receives data from potentially untrusted external networks (PSTN, VoIP). Never pass raw caller ID strings to logging systems or display UIs without sanitisation. Malformed caller ID strings can contain SQL injection payloads, XSS vectors, or control characters that disrupt terminal output.Engineering Design Insights
A production-grade CallControl service implementation must handle several edge cases. The Call action should validate the CallURI parameter format using a URI parser that rejects malformed or unsupported URI schemes before attempting to place the call. For conference scenarios, implement a conference bridge map that tracks participant CallID values independently of individual call state machines. When a conference participant hangs up, their call transitions to TERMINATED but the conference bridge continues for remaining participants. Finally, the service must support MaxCallCount as advertised in the device description — if the maximum number of concurrent calls is reached, the Call action should fail gracefully with a MAX_CALLS_REACHED error.
Frequently Asked Questions
Q1: Can the CallControl service handle multiple simultaneous calls?
Yes, up to the limit advertised in the device’s
Yes, up to the limit advertised in the device’s
MaxCallCount parameter. Each call is tracked with a unique CallID and has its own state machine instance.Q2: How does the service differentiate between incoming and outgoing calls?
The state machine is identical for both directions. For incoming calls, the first state observed is ALERTING (the device is being alerted about an incoming call). For outgoing calls, the first state after IDLE is DIALLING.
The state machine is identical for both directions. For incoming calls, the first state observed is ALERTING (the device is being alerted about an incoming call). For outgoing calls, the first state after IDLE is DIALLING.
Q3: Does the standard support emergency call handling?
The standard does not define special emergency call procedures. However, implementations should ensure that emergency numbers (e.g., 112, 911) can always be dialled regardless of device lock state or call limits.
The standard does not define special emergency call procedures. However, implementations should ensure that emergency numbers (e.g., 112, 911) can always be dialled regardless of device lock state or call limits.
Q4: What is the recommended approach for call history?
Call history is not part of the CallControl service specification. Implementations should maintain call history through a vendor-specific service or through the Phonebook service’s metadata extensions, storing completed call records with timestamps and duration.
Call history is not part of the CallControl service specification. Implementations should maintain call history through a vendor-specific service or through the Phonebook service’s metadata extensions, storing completed call records with timestamps and duration.
