ISO/IEC DIS 29341-25-1

Information technology -- UPnP Device Architecture

Technologies de l'information -- Architecture de dispositif UPnP

Standards Content (sample)

DRAFT INTERNATIONAL STANDARD ISO/IEC 29341-25-1
Attributed to ISO/IEC JTC 1 by the Central Secretariat (see page iii)
Voting begins on Voting terminates on
2015-09-03 2015-12-03

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION  МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ  ORGANISATION INTERNATIONALE DE NORMALISATION

INTERNATIONAL ELECTROTECHNICAL COMMISSION  МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОММИСИЯ  COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE

PUBLICLY AVAILABLE SPECIFICATION PROCEDURE
Information technology — UPnP Device Architecture
Part 25-1:
Telephony device control protocol — Telephony architecture
Technologies de l'information — Architecture de dispositif UPnP —
Partie 25-1
ICS 35.200

This Publicly Available Specification (PAS) is being submitted for Fast-track processing in

accordance with the provisions of ISO/IEC JTC 1 Directives.

THIS DOCUMENT IS A DRAFT CIRCULATED FOR COMMENT AND APPROVAL. IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT BE

REFERRED TO AS AN INTERNATIONAL STANDARD UNTIL PUBLISHED AS SUCH.

IN ADDITION TO THEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, TECHNOLOGICAL, COMMERCIAL AND USER PURPOSES,

DRAFT INTERNATIONAL STANDARDS MAY ON OCCASION HAVE TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL TO BECOME

STANDARDS TO WHICH REFERENCE MAY BE MADE IN NATIONAL REGULATIONS.

RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT, WITH THEIR COMMENTS, NOTIFICATION OF ANY RELEVANT PATENT RIGHTS OF WHICH

THEY ARE AWARE AND TO PROVIDE SUPPORTING DOCUMENTATION.
International Organization for Standardization, 2015
International Electrotechnical Commission, 2015
---------------------- Page: 1 ----------------------
ISO/IEC DIS 29341-25-1
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2015

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any

means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.

Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.

ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2015 — All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC DIS 29341-25-1
NOTE FROM ITTF

The ballot on the transposition of a PAS into an International Standard follows the JTC 1 PAS procedures

contained in the JTC 1 Supplement, F.3.

Reflecting the importance of the PAS process, the JTC 1 secretariat shall also inform JTC 1 national bodies

and Liaison Organisations, and those organisations authorized to be PAS submitters, of the initiation of any

PAS ballot, the results of the ballot, and the identity of the JTC 1 subcommittee which will be responsible for

any future work.

For ballot, JTC 1 National Bodies and the PAS Submitter shall receive both the PAS to be transposed and the

accompanying Explanatory Report. During the ballot JTC 1 members may propose changes to the PAS.

These can be resolved with the PAS Submitter after completion of the ballot.

The period for combined DIS voting shall be five months. In order to be accepted the DIS must be supported

by 75 % of the votes cast (abstention is not counted as a vote) and by two-thirds of the P-members voting of

JTC 1.

In the case of a failure of the ballot, JTC 1 shall make known to the Submitter the reasons which have led to

the negative result. Based on this information, the Submitter may choose to re-submit a modified specification

as a new PAS submission.

Once the Draft International Standard has been approved by JTC 1, it shall progress to the approval stage

(FDIS).
© ISO/IEC 2015 — All rights reserved iii
---------------------- Page: 3 ----------------------
Normative Terminology Changes
You must use the command Old LoCase from the Review group of the UPnP ribbon tab

to locate and process lower case terms whose ISO/IEC meanings differ from their former

UPnP meanings. Each such term is marked with a hidden bookmark, so there is no other

easy way to identify them. (The former macro, Review_OldLowerCase_Terms, has
been removed from the Word template upnp4iecAdjunct.dotm.)
Unlike upper case normative terms, lower case terms with new meanings cannot be

mechanically corrected in the conversion for ISO/IEC. Each Working Committee needs to

evaluate each of these terms in context to determine what changes to make.
Marked terms fall into one of the four following categories:
• Non-normative in UPnP (possibly with normative intent) → normative in ISO/IEC.
Examples: “required”, “shall”, “recommended”, “should”, “may”.

• Do not change: Instances that actually had normative intent, but were not upper-

cased.
• Change: Instances that really were non-normative, to remain non-normative.
• Non-normative in UPnP (possibly with normative intent) → statutory (legal or
regulatory compliance) in ISO/IEC.
Example: “must”.
• Do not change: Instances that actually had statutory intent.

• Change: Instances that actually had normative intent, but were not upper-cased.

Example: “must” → “shall”.
• Change: Instances that really were non-normative, to remain non-statutory.
• Non-normative in UPnP (probably with normative intent) → non-normative in
ISO/IEC.
Examples: “mandatory”, “prohibited”, “optional”.

• Change: Instances that actually had normative intent, to be normative in ISO/IEC.

Common replacements:
“mandatory” → “required” “… is mandatory” → “shall …”
“prohibited” → “not allowed”
“optional” → “allowed”

• Change: Instances of “mandatory” and “prohibit(s | ed | ing | ion)” that really were

non-normative, to remain non-normative. The ISO/IEC Directives use the word
“prohibit” in the definition of normative terms, and the word “mandatory” even
more broadly in the definition of both normative and statutory terms.
• No need to change: Non-normative instances of “optional”.
• Non-normative in UPnP → normative in ISO/IEC.
Examples: “ought”, “allow”, “permissible”, “permit”, “accept”.
Change: All instances, to avoid becoming normative.
More information about ISO/IEC normative (and more general “provisioning”)
terms may be found in the ISO/IEC Directives, Part 2, Annex H.
---------------------- Page: 4 ----------------------
Table 0 — Open issues for ISO/IEC conversion
Document
a b c
Locations
Status Description UPnP Notes
2 Moved UDA 1.0 from informative to normative
references. Since architecture document is normative,
its references to UDA are also normative.
Removed RFC 2119 from references, since it no longer
applies. Note that, had it been retained, it would have
been a normative reference.
[1] Added the bookmark named ‘deviceRef’ for UDA 1.0.
Removed the bookmark named ‘igdRef’ that had been
associated with the UDCA entry. It was not referenced,
and, presumably, was an inadvertent holdover from
another document.
3 Note that the abbreviated terms have been included
with the terms themselves. This is the proper
presentation for ISO/IEC documents.
Some Telephony documents that were converted
earlier have separated the abbreviations from their
expansions. These should be corrected in those
documents.
# All document-internal cross-references to figures and
sections (now clauses, subclauses and annexes) were
hard-coded. All known occurrences were corrected.
Annex B IPv6 and Naming Conventions refs are retained as
informative, since they are not referenced in this
document.
# Hanging paragraphs, singleton subdivisions
G-U
When a clause/subclause is subdivided into subclauses
or an annex is subdivided into clauses, neither hanging
paragraphs nor singleton subdivisions are allowed.
• A hanging paragraph is any text, table, figure or
any other content between the parent numbered
paragraph and the first child subdivision.
• A singleton subdivision is when there is only one
subdivision at any level. There must be at least 2.
Pending GSC action: GSC will provide a command to
detect both hanging paragraphs and singleton
subdivisions.
Pending UPnP action: UPnP editors should correct all
hanging paragraphs and singleton subdivisions as they
encounter them, but the tool to identify them is coming.
# Notes and Examples
G-U
The ISO/IEC Directives require that Notes and
Examples be set off by a distinctive font style and/or
indentation. Notes and Examples are also not allowed
to contain normative statements.
Pending GSC action: GSC will provide a command for
the following UPnP use:
Pending UPnP action: UPnP editors will use new
command to walk through the document, stopping at
each Note and Example that does not use the IEC ¶
style “NOTE”. Proper informative instances need to be
restyled. Instances with normative content need to be
reworded, or the normative content moved elsewhere.
Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 5 ----------------------
Document
a b c
Locations
Status Description UPnP Notes
# Cross-reference form
G-U
The ISO/IEC Directives require that all document cross-
references to tables, figures, clauses, subclauses and
subclauses be to the referent’s (alpha)numeric
designator, not to its title/caption/label.
Pending GSC action: GSC will provide a command for
the following UPnP use:
Pending UPnP action: UPnP editors will use new
command to walk through the document, stopping at
each cross-reference that references the target’s text
instead of its alphanumeric designator, so that the
editor can correct it.
— Remove old styles
This document still contains ¶ and character styles
used before the ISO/IEC conversion. These style need
to be removed.
Pending GSC action: GSC will provide a command
that will automatically remove all of the old styles.
— Use only approved styles
Word 2007 and 2010 can be configured to disable use
of all styles not in the approved style sets for UPnP and
ISO/IEC documents.
Pending GSC action: GSC will provide a command to
toggle the allowing and disallowing of unapproved
styles.
— Dual publishers
G-U
UPnP specifications are intended to be published by
both UPnP and ISO/IEC. There are some minor
differences in content and style between the two
publishers.
Pending GSC action: GSC will provide a command to
toggle between publishers and check for document
features disallowed by the designated target publisher.
This includes but is not limited to:
• Normative references may include UPnP
documents when UPnP is the publisher. Only their
ISO/IEC equivalents are allowed in ISO/IEC
publications.
• Header/footer contents differ.
• Self-references to “this document” in UPnP
become “this part of ISO/IEC 29341” in ISO/IEC.
Pending UPnP action: Be aware of and manage these
differences when preparing final versions for
publication.
Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 6 ----------------------
Document
a b c
Locations
Status Description UPnP Notes
Status key:
Informational, requires no action by anyone.
G An issue that awaits action by G Shults Consulting (GSC).

G-U An issue that awaits action by GSC, and then requires follow-up action by UPnP.

U An issue that requires action by UPnP.

U? An issue that GSC considers closed, but UPnP might disagree. UPnP should review.

AU An issue that was resolved during conversion by GSC, but that UPnP needs to understand to avoid

problem recurrence
✓ Issue is closed.
Document Locations:
# Numerous instances, not specifically identified.
— Document generic, not tied to specific locations.
GSC: G Shults Consulting, ISO/IEC conversion contractor
Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 7 ----------------------
TelephonyArchitecture:1
For UPnP Version 1.0
Status: Standardized DCP (SDCP)
Date: March 22, 2011
Document Version: 1.0
Service Template Version: 2.00

This Standardized DCP has been adopted as a Standardized DCP by the Steering Committee

of the UPnP Forum, pursuant to Section 2.1(c)(ii) of the UPnP Forum Membership Agreement.

UPnP Forum Members have rights and licenses defined by Section 3 of the UPnP Forum

Membership Agreement to use and reproduce the Standardized DCP in UPnP Compliant

Devices. All such use is subject to all of the provisions of the UPnP Forum Membership

Agreement.
THE UPNP FORUM TAKES NO POSITION AS TO WHETHER ANY INTELLECTUAL
PROPERTY RIGHTS EXIST IN THE STANDARDIZED DCPS. THE STANDARDIZED DCPS
ARE PROVIDED "AS IS" AND "WITH ALL FAULTS". THE UPNP FORUM MAKES NO
WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO
THE STANDARDIZED DCPS, INCLUDING BUT NOT LIMITED TO ALL IMPLIED
WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A
PARTICULAR PURPOSE, OF REASONABLE CARE OR WORKMANLIKE EFFORT, OR
RESULTS OR OF LACK OF NEGLIGENCE.
Copyright © 2011 UPnP Forum. All rights Reserved.
Authors Company
Mahfuzur Rahman (Editor) Samsung
Yoshiki Nishikawa NTT
Jeyoung Maeng Samsung
Enrico Grosso Telecom Italia

The UPnP forum in no way guarantees the accuracy or completeness of this author list and in no way implies

any rights for or support from those members listed. This list is not the specifications’ contributor list that is kept

on the UPnP Forum’s website.
Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 8 ----------------------
CONTENTS

1 Scope ............................................................................................................................... 7

2 Normative references ........................................................................................................ 7

3 Terms, definitions and abbreviated terms .......................................................................... 7

4 Text conventions .............................................................................................................. 9

5 Introduction ...................................................................................................................... 9

6 Telephony Reference Architecture .................................................................................. 10

6.1 Telephony Basic Architecture Paradigm ................................................................. 10

6.2 Telephony Components Overview .......................................................................... 12

6.2.1 Call Management Service .......................................................................... 13

6.2.2 Media Management Service ....................................................................... 14

6.2.3 Interaction of Media and Call Management Service .................................... 14

6.2.4 Messaging Service ..................................................................................... 15

6.2.5 Phone Management via Data Model ........................................................... 16

6.2.6 InputConfig Service .................................................................................... 17

6.2.7 Security ..................................................................................................... 17

Annex A (informative) Deployment Scenarios ....................................................................... 19

Annex B (informative) Bibliography ....................................................................................... 26

Figure 1 — UPnP Telephony Basic Architecture .................................................................... 10

Figure 2 — Architecture with a Telephny Control Point (TelCP) on an independent

Device (3-Box Model) ............................................................................................................ 11

Figure 3 — Service Level Architectural View .......................................................................... 11

Figure 4 — UPnP Devices and Services for Telephony Architecture ....................................... 12

Figure 5 — A Deployment Scenario with Two Telephony Server Devices in a Single

Physical Box ......................................................................................................................... 13

Figure 6 — Call Management Service .................................................................................... 14

Figure 7 — Media Management Service ................................................................................ 14

Figure 8 — Architecture for Media Management Service ........................................................ 15

Figure 9 — Messaging Service Interaction Diagram ............................................................... 16

Figure 10 — Phone Management via Data Model Interaction Diagram .................................... 16

Figure 11 — Architecture for InputConfig Service (IS) ............................................................ 17

Figure 12 — Architecture for Security Service ........................................................................ 18

Figure A.1 — Architecture with Telephony Control Point on a TV ........................................... 19

Figure A.2 — Deployment with a TelCP on a TC - Multiple TV Model ..................................... 19

Figure A.3 — Deployment with a TelCP on a TV - Multiple Phone Model ................................ 20

Figure A.4 — An Architecture with a Telephony Control Point (TelCP) and a Telephony

Client (TC) on a TV (2-Box Model) ........................................................................................ 20

Figure A.5 — Deployment model with a Telephony Control Point (TelCP) and a

Telephony Client (TC) on a TV (2-Box Model) – Multiple TV Model ....................................... 21

Figure A.6 — Deployment model with a Telephony Control Point (TelCP) and a

Telephony Server (TS) on a Phone (2-Box Physical Model).................................................... 21

Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 9 ----------------------
Figure A.7 — Deployment with a phone having a Telephony Server (TS) and a

Telephony Control Point (TelCP) - Multiple TV Model ............................................................. 22

Figure A.8 — Deployment with a Telephony Control Point (TelCP) on a Phone ....................... 22

Figure A.9 — Deployment with a Telephony Control Point (TelCP) on a Phone – Multiple

TV Model .............................................................................................................................. 23

Figure A.10 — Deployment with an independent Telephony Control point (TelCP) -3 Box

Scenario ............................................................................................................................... 23

Figure A.11 — Deployment with an independent Telephony Control Point (TelCP) – 3-

Box with Multiple TV Model ................................................................................................... 24

Figure A.12 — Messaging Service Deployment with Phone as the Messaging

Aggregator ............................................................................................................................ 24

Figure A.13 — Multiple Telephony Servers in a telephone ...................................................... 25

Table 0 — Open issues for ISO/IEC conversion ....................................................................... 2

1 Scope

This document describes an architecture that allows UPnP Telephony devices, services and

control points defined in the propoded DCP to be deployed in the home network environment

and to enable management of incoming and outgoing telephony calls, messaging, presence

information and phone features configuration through UPnP means from devices within the

home.

In order to accommodate the above mentioned goals, the Telephony Architecture defines

several UPnP devices and services that can be embedded to the devices defined for telephony.

The architecture model describes interaction among the telephony devices, services and

control points. The architecture also describes various deployment scenarios.

The architecture does not describe any interfaces to “service” gateways that will enable non-

UPnP entities to interact with the UPnP devices, services and control points physically attached

to the home network.
2 Normative references
[1] – UPnP Device Architecture, version 1.0.

Available at: http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf.

Latest version available at: http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-

v1.0.pdf.

[RFC 2119] – S. Bradner, RFC 2119: Key words for use in RFCs to Indicate Requirement

Levels, 1997.
Available at: http://www.faqs.org/rfcs/rfc2119.html.
3 Terms, definitions and abbreviated terms

For the purposes of this document, the terms and definitions given in [1] and the following

apply.
Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 10 ----------------------
3.1 Provisioning terms
3.1.1
conditionally allowed

The definition or behavior depends on a condition. If the specified condition is met, then the

definition or behavior is allowed, otherwise it is not allowed.
3.1.2
conditionally required

The definition or behavior depends on a condition. If the specified condition is met, then the

definition or behavior is required, otherwise it is not allowed.
3.1.3
not allowed

The definition or behavior is prohibited by this specification. Opposite of required.

3.2 Symbols
3.2.1

signifies a hierarchical parent-child (parent::child) relationship between the two objects

separated by the double colon. This delimiter is used in multiple contexts, for example:

Service::Action(), Action()::Argument, parentProperty::childProperty.
3.3 General telephony terms
3.3.1
Telephony Server

The term Telephony Server (TS) refers to a logical device that provides common telephony

features (e.g. call/video call, messaging, address book) via UPnP to other devices in the home

network. A TS is usually connected to a telephony service on its WAN interface, either wire line

or mobile. For example, a TS may be a mobile phone or a home gateway with VoIP features.

3.3.2
Telephony Client

The term Telephony Client (TC) to a networked logical device that allows the user to enjoy the

telephony features provided by the Telephony Server via UPnP. A TC may usually provide

input/output features for voice and video. An example of a TC is a networked TV Set.

3.3.3
Telephony Control Point
TelCP

The term Telephony Control Point (TelCP) refers to a software feature able to control the

functionalities of both TS and TC. It may be embedded in a TS, a TC or also being a physical

device on its own.
3.3.4
InputConfig Control Point
ICP

The Term InputConfig Control Point (ICP) refers to a software feature that is able to control the

functionalities of UPnP devices to be used to provide user-friendly input features. The control

here refers to getting capabilities of UPnP dveices to be used for input, matching capabilities

and selecting the appropriate dveice role such as receving side or sending side etc.

Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 11 ----------------------
3.3.5
InputConfig Service

The Term InputConfig Service (InputConfig) refers to a software feature that is able to provide

user-friendly input capability via UPnP means and expose interfaces to describe capabilities of

sender/receiver of devices to be used for input services and setup the input session between

the devices using the matching profile (capability) from the ICP .
4 Text conventionsNotations

• In this document, features are described as Required, Recommended, or Optional as

follows:
The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,”
“SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this specification are to
be interpreted as described in [RFC 2119].
In addition, the following keywords are used in this specification:

PROHIBITED – The definition or behavior is an absolute prohibition of this specification.

Opposite of REQUIRED.

CONDITIONALLY REQUIRED – The definition or behavior depends on a condition. If the

specified condition is met, then the definition or behavior is REQUIRED, otherwise it is

PROHIBITED.

CONDITIONALLY OPTIONAL – The definition or behavior depends on a condition. If the

specified condition is met, then the definition or behavior is OPTIONAL, otherwise it is

PROHIBITED.

These keywords are thus capitalized when used to unambiguously specify requirements

over protocol and application features and behavior that affect the interoperability and

security of implementations. When these words are not capitalized, they are meant in their

natural-language sense.
• Strings that are to be taken literally are enclosed in “double quotes”.
• Words that are emphasized are printed in italic.

• Keywords that are defined by the UPnP Working Committee are printed using the forum

character style.

• Keywords that are defined by the UPnP Device Architecture are printed using the arch

character style.

• A double colon delimiter, “::”, signifies a hierarchical parent-child (parent::child) relationship Comment [GSC1]:

Moved to Symbols in Clause 3.

between the two objects separated by the double colon. This delimiter is used in multiple

contexts, for example: Service::Action(), Action()::Argument, parentProperty::childProperty.

5 Introduction

The objective of the UPnP Telephony specification is to provide a means for interactions

between telephony devices and other (non-telephony) devices, without using native telephony

features, but exploiting UPnP features of the phone device (e.g. messaging, calling, presence,

etc.).

An examtple of such a scenario, for a calling use case, is shown in Figure 1 Figure 1 where a

Phone device communicates with a non-phone (TV) using UPnP interaction model. The non-

phone device as shown here is a TV, and using UPnP mechanism can control the phone device

which receives call from outside of the home network via non-UPnP means. However, this

phone device can make the media session for this call available in the UPnP network to other

non-phone device via UPnP mechanism. The non-phone device can have a control point that

can control this media session via UPnP control mechanism on the phone device. The phone

Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 12 ----------------------

device and the non-phone device establishes media session for the call between them and this

media session gets established using UPnP command and control mechanism.
Phone
Out of scope
of UPnP
Home Network
TV Phone
Control
Telephony
Control Notification
Phone
Point Telephony
Network
Server
Media
(TS)
Telephony
Client
Figure 1 — UPnP Telephony Basic Architecture

Also the other use cases such as messaging, managing local presence, managing contacts

and accessing presence information, and managing the phone configuration are addressed by

the Telephony DCP according to this basic architecture model.

Note It must be noted that the interaction of actual telephony call with a callee or a caller, on

any kind of telecommunication network (PSTN/ISDN, Mobile, Internet), is handled by the phone

device and is out of scope of this specification.
6 Telephony Reference Architecture
6.1 Telephony Basic Architecture Paradigm

Clause 6 This section of the document describes the basic architectural model for telephony

features.

The basic architecture for UPnP telephony features can be described in a 3-box model which is

shown below in Figure 2 Figure 2. . Figure 2 Figure 2 represents a 3-box model where the

Telephony Control Point (TelCP) resides on a box outside of the Telephony Server (TS) and

the Telephony Client (TC). The Telephony Control Point (TelCP) discovers both the Telephony

Client (TC) and the Telephony Server (TS) and can establish the media session between them.

And can control the media session between the Telephony Client (TC) and the Telephony

Server (TS). This model can be collapsed into a 2-box model by having the Telephony Control

Point (TelCP) reside either in the Telephony Server (TS) or the Telephony Client (TC). The

Telephony Control Point (TelCP) can also directly interact with the Telephony Server (TS)

without needing an interaction with a Telephony Client (TC) or without residing in the

Telephony Client (TC). This is the case when realizing a number of features such as presence

and messaging services, notifications, initiating a call etc.
Copyright © 2011 UPnP Forum. All rights Reserved.
---------------------- Page: 13 ----------------------
PDA
Telephony
Control
Control
Point
Control
(TelCP)
TV Phone
Notification Notification
Telephony Telephony
Client Server
Media/Data
(TC)
(TS)

Figure 2 — Architecture with a Telephny Control Point (TelCP) on an independent Device

(3-Box Model)

The diagram below shows a more detailed view on the interactions between a Telephony

Control Point (TelCP), a Telephony Server (TS) and a Telephony Client (TC). The Telephony

Server (TS) and the Telephony Client (TC) are UPnP devices. A Telephony Client (TC) and a

Telephony Server (TS) devices consists of a set of services and the Telephony Control Point

(TelCP) basically interacts with the services using UPnP actions. The actual communication

between TC and TS devices for media streams
...