SIST-TS TS 101 884-1 V4.1.1:2004

Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; Technology Mapping; Part 1: Implementation of TIPHON architecture using SIP

This work item will deliver a mapping of the TIPHON architecture to the SIP protocol.

Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON), 4. izdaja - 1. del: Tehnologija preslikave - Implementacija arhitekture TIPHON z uporabo SIP

General Information

• Status: Published
• Publication Date: 31-Mar-2004
• ICS: 33.020 - Telecommunications in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Apr-2004
• Due Date: 01-Apr-2004
• Completion Date: 01-Apr-2004
• Ref Project: ETSI TS 101 884-1 V4.1.1 (2003-08) - Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; Technology Mapping; Part 1: Implementation of TIPHON architecture using SIP

Standards Content (Sample)

SLOVENSKI STANDARD
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON), 4.
izdaja - 1. del: Tehnologija preslikave - Implementacija arhitekture TIPHON z
uporabo SIP
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON)
Release 4; Technology Mapping; Part 1: Implementation of TIPHON architecture using
SIP
Ta slovenski standard je istoveten z: TS 101 884-1 Version 4.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON) Release 4;
Technology Mapping;
Part 1: Implementation of TIPHON architecture using SIP

2 ETSI TS 101 884-1 V4.1.1 (2003-08)

Reference
RTS/TIPHON-03018-1R4
Keywords
architecture, IP, SIP, telephony, VoIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
[e-mail]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI TS 101 884-1 V4.1.1 (2003-08)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.7
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.8
4 SIP environment overview .8
4.1 Introduction.8
4.2 SIP protocol.9
4.2.1 SIP signalling, methods and responses .9
4.2.1.1 SIP signalling.9
4.2.1.2 Methods and responses .9
4.2.2 SIP protocol components .10
4.3 SDP.10
4.4 HTTP/1.1.10
5 Implementation of TIPHON functional architecture using SIP .10
5.1 Introduction.10
5.2 SIP functional architecture .10
6 Registration service.12
6.1 Introduction.12
6.2 Registration functional entities mapping.14
6.3 Registration Messages Mapping.14
6.4 Registration information flow Mapping.15
6.4.1 Relationship ra (RFE1/RFE2).15
6.4.2 Relationship rb (RFE2/RFE3).17
6.4.3 Relationship rc (RFE1/RFE3).18
6.4.4 Relationship rd (RFE2/RFE4).18
6.5 Registration action Mapping .19
6.6 Conclusion.19
7 Simple call application .20
7.1 Introduction.20
7.2 Simple call functional entities mapping .24
7.3 Simple call messages mapping.24
7.4 Simple call information flow mapping.25
7.4.1 Relationship ra (CallingUser/CFE1).26
7.4.2 Relationship rf, ri (CFE3/CFE6/CFE9) .28
7.4.3 Relationship rl (CFE11/CalledUser).30
7.5 Simple call functional entity actions mapping.32
7.6 Timers.33
7.7 Conclusion.34
8 Media Control service .34
8.1 Introduction.34
8.2 Media Control functional entities mapping .34
8.3 Media Control information flow Mapping .34
8.3.1 Relationship ra (CCA/MFE1).35
8.4 Conclusion.36
9 Transport.36
9.1 Introduction.36
10 Supplementary services.36
ETSI
4 ETSI TS 101 884-1 V4.1.1 (2003-08)
11 Control of end-to-end Quality of Service.36
11.1 Introduction.36
11.2 Control of end-to-end Quality of Service functional entities mapping.37
11.3 Control of end-to-end Quality of Service flows mapping .37
11.4 Control of end-to-end Quality of Service information flow data mapping.39
11.4.1 Relationship ra (CallingUser/QFE1).39
11.4.2 Relationship rc, rd (QFE2/QFE8/QFE3) .40
11.4.3 Relationship rf (QFE4/CalledUser) .42
11.4.4 Relationship rg (QFE1/QFE5) .42
11.5 Control of end-to-end Quality of Service functional entity actions mapping.43
11.6 Timers.43
11.7 Conclusion.44
12 Security service.44
Annex A (informative): Bibliography.48
History .49

ETSI
5 ETSI TS 101 884-1 V4.1.1 (2003-08)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
The present document is part 1 of a multi-part deliverable covering implementation, of TIPHON architecture using the
SIP protocol, as identified below:
Part 1: "Implementation of TIPHON architecture using SIP";
Part 2: "Implementation Profile for SIP".
ETSI
6 ETSI TS 101 884-1 V4.1.1 (2003-08)
1 Scope
The present document describes how the SIP protocol [9] completed with correlated protocols like SDP [11],
HTTP [12] can be a candidate for TIPHON release 4 according to guidelines given in TS 101 315 Release 4 (see
bibliography) and TS 101 315 Release 3 [2].
The SIP profile is derived from the examination of the following TIPHON Release 4 documents:
• the TIPHON baseline architecture described in TS 101 314 [1];
• the capabilities service required by TS 101 878 (see bibliography);
• the Meta-protocol as defined in multi part document TS 101 882-1 [5], TS 101 882-2 [6], TS 101 882-3 (see
bibliography), TS 101 882-4 (see bibliography) and TS 101 882-5 [7];
• the end-to-end Quality of Service defined in TS 102 024-3 [3];
• the Security service defined in TS 102 165-1 [4].
The mapping of Meta-Protocol to SIP is limited to the following parts, while other parts are not available yet like
supplementary services:
• Registration Meta-Protocol [6];
• Simple Call Meta-Protocol (TS 101 882-3 - see bibliography);
• Media Control Meta-Protocol (TS 101 882-4 - see bibliography);
• the end-to-end Quality of Service defined in TS 102 024-3 [3];
• IETF RFC 3261: "SIP: Session Initiation Protocol" [9];
• IETF RFC 2327: "SDP: Session Description Protocol" [11];
• IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1" [12];
• IETF RFC 2617: "HTTP Authentication: Basic and Digest Authentication" (see bibliography);
Furthermore the following documents have been consulted for information:
• TS 124 229: "IP Multimedia Call Control Protocol based on SIP and SDP" (see bibliograpy);
• TS 124 228: "Signalling flows for the IP multimedia call control based on SIP and SDP" [8].
ETSI
7 ETSI TS 101 884-1 V4.1.1 (2003-08)
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
[1] ETSI TS 101 314: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 4; Abstract Architecture and Reference Points Definition; Network
Architecture and Reference Points".
[2] ETSI TS 101 315: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 3; Functional entities, information flow and reference point definitions;
Guidelines for application of TIPHON functional architecture to inter-domain services".
[3] ETSI TS 102 024-3: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 4; End-to-end Quality of Service in TIPHON Systems; Part 3: Signalling and
Control of end-to-end Quality of Service".
[4] ETSI TS 102 165-1: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 4; Protocol Framework Definition; Methods and Protocols for Security; Part 1:
Threat Analysis".
[5] ETSI TS 101 882-1: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 4; Protocol Framework Definition; Part 1: Meta-protocol design rules,
development method, and mapping guideline".
[6] ETSI TS 101 882-2: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 4; Protocol Framework Definition; Part 2: Registration and Service
Attachment service meta-protocol definition.".
[7] ETSI TS 101 882-5: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON) Release 4; Protocol Framework Definition; Part 5: Transport control service meta-
protocol definition;".
[8] ETSI TS 124 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Signalling flows for the IP multimedia call control based
on SIP and SDP; Stage 3 (3GPP TS 24.228 version 5.3.0 Release 5)".
[9] IETF RFC 3261: "SIP: Session Initiation Protocol".
[10] IETF RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)".
[11] IETF RFC 2327: "SDP: Session Description Protocol".
[12] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1".
[13] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication".
[14] IETF RFC 1890: "RTP Profile for Audio and Video Conferences with Minimal Control".
[15] IETF RFC 1889: "RTP: A Transport Protocol for Real-Time Applications".
[16] IETF RFC 2806: "URLs for Telephone Calls".
[17] IETF RFC 2748: "The COPS (Common Open Policy Service) Protocol".
ETSI
8 ETSI TS 101 884-1 V4.1.1 (2003-08)
[18] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)".
[19] IETF RFC 3525: "Gateway Control Protocol Version 1".
[20] IETF RFC 3265: "Session Initiation Protocol (SIP)-Specific Event Notification".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TS 101 314 [1] and TS 101 878 (see
bibliography) apply.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
B2BUA Back-to-Back User Agent
BC Bearer Control
CC Call Control
COPS Common Open Policy Service
FG Functional Group
ICF Inter-Connect Function
IP Internet Protocol
MC Media Control
NFG Network Functional Group
PCM Pulse Code Modulation
PDP Policy Decision Point
PSTN Public Switched Telephone Network
QoS Quality of Service
RPC Remote Procedure Call
SAP Service Access Point
SC Service Control
SDP Session Description Protocol
SpoA Service point of Attachment
TE Terminal Equipment
UA User Agent
UAC User Agent Client
UAS User Agent Server
URI Uniform Resource Identifier
4 SIP environment overview
4.1 Introduction
The purpose of the present document is not to describe how to implement SIP protocol but how TIPHON protocol can
be represented in a SIP environment. For example parameter mandatory in SIP but without equivalence in TIPHON
information elements are not documented. Mandatory behaviours in SIP that do not correspond to any TIPHON
behaviours are not documented either.
The aim is to identify gap in TIPHON to SIP direction between both protocols. Informative suggestions to fill those
gaps could be given in conclusion.
ETSI
9 ETSI TS 101 884-1 V4.1.1 (2003-08)
4.2 SIP protocol
SIP is a relatively new technology (1995) developed for remote control, establishment and tear-down of multimedia
sessions. The origins of SIP are in the academic and IETF community and assumed in its first incarnation a public
internet although with the interest shown by 3GPP the application to a managed network that uses IP has become
ascendant. SIP is based upon the communication model of HTTP and therefore is broadly viewed as a request-response
protocol. In relation to other well known protocols SIP has close cousins in Remote Procedure Call (RPC) and in the
ITU-T ROSE protocol.
According to RFC 3261 [9], SIP is an application-layer-control protocol to manage multimedia session. But, "SIP is not
a vertically integrated communications system", and will need other IETF protocols to build a complete multimedia
architecture (e.g.: RTP RFC 1889 [15], RTSP RFC 2326 [18], MEGACO RFC 3525 [19], SDP RFC 2327 [11]).
The choice of the protocol for the session description is opened in SIP and appears in SIP only as a parameter value
(Content-Type). The media type descriptions that can be included in the body of a SIP message are Internet Media
Types as in HTPP/1.1. However, in this profile only Session Description Protocol (SDP) defined in RFC 2327 [11] has
been considered. SIP reuses also the authentication mechanism defined in HTTP.
The SIP technology has been considered through the following standards:
• "SIP: Session Initiation Protocol" - RFC 3261 [9].
• "SDP: Session Description Protocol" - RFC 2327 [11].
• "RTP Profile for Audio and Video Conferences with Minimal Control" - RFC 1890 [14].
• "Hypertext Transfer Protocol - HTTP/1.1" - RFC 2616 [12].
SIP does not define services. Rather, SIP provides primitives that can be used to implement different services. For
example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a
session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same
primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily
implemented. As this example shows, a single primitive is typically used to provide several different services.
SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference
is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP
messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide
any kind of network resource reservation capabilities.
The nature of the services provided make security particularly important. To that end, SIP provides a suite of security
services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity
protection, and encryption and privacy services.
SIP works with both IPv4 and IPv6.
4.2.1 SIP signalling, methods and responses
4.2.1.1 SIP signalling
The SIP protocol client/server machine is very simple: Request is sent and the requestor (client) waits for a response.
The request contains the method and who the method is aimed at, the response contains the status code that informs the
requestor of how the server has dealt with the request.
4.2.1.2 Methods and responses
There are 6 core methods in SIP and these are the basis of the protocol:
• INVITE - starts a session (and modifies it if used as a re-invite).
• ACK - confirms the invite.
• BYE - terminates a sessions.
ETSI
10 ETSI TS 101 884-1 V4.1.1 (2003-08)
• CANCEL - cancel an invite.
• OPTIONS - Querying capability.
• REGISTER - binds a user's address (SIP name) to a network address (IP address).
4.2.2 SIP protocol components
The protocol of SIP is enabled by assigning particular functions to a set of protocol components. A particular SIP
device will contain 1 or more of these components.
• User Agent Client (UAC).
• User Agent Server (UAS).
• Redirect server.
• Proxy server.
• Registrar.
The UAC and UAS exist in a normal terminal device and are termed jointly the User Agent.
The proxy server arises from breaking the assumption that the UACs know the UASs that they want to communicate
with. In anything but the smallest of networks this assumption is inevitably broken so a network resident proxy to the
UA exists to facilitate routing.
• Proxy servers can be configured to perform inter-domain call establishment.
• The registrar server is a special server that attends to REGISTER methods. In most cases the registrar and
proxy server will be co-located.
4.3 SDP
SDP is a session description protocol in text format language. It is used in SIP to define a simple offer/answer model to
a describe unicast session. Mapping in the present document has been based on RFC 2327 [11] overloaded with
RFC 3264 [10].
4.4 HTTP/1.1
Hypertext Transfer protocol provides a scheme description for authentication.
According to RFC 3261 [9], chapter 22, only the "Digest" authentication mechanism described in RFC 2617 [13]
overload by RFC 3261 [9] has to be considered.
5 Implementation of TIPHON functional architecture
using SIP
5.1 Introduction
5.2 SIP functional architecture
The SIP Architecture has the following functional elements, as defined in [9].
User Agent (UA): The user agent is the functional entity that may initiate or respond to a SIP request.
ETSI
11 ETSI TS 101 884-1 V4.1.1 (2003-08)
In a TIPHON compliant system, the SIP User Agent (UA) shall provide the functionality of the terminal functional
group. The terminal functional group performs the roles of the terminal registration functional group, originating
terminal functional group and the terminating terminal functional group. The reference points S1, SC1 and N1 are
regarded as internal to the TE.
Back-to-Back User Agent (B2BUA): B2BUA is a logical entity that receives a request and processes it as a User
Agent Server (UAS). In order to determine how a request should be answered, it acts as a User Agent Client (UAC) and
generates requests. Unlike a proxy server (stateless), it maintains a dialogue state, and must participate in all requests
sent on the dialogues it has established. TIPHON recommends the use of a B2BUA, as network functional groupings
involved in providing a service.
Proxy server: A proxy server acts as both the client and server: It receives a request from an entity, and initiates a
request on behalf of the requesting entity, hence acting as a server for the requesting entity. A proxy server can be
stateless (forgets about the state of a particular session) or statefull (keeps track of the state of the session it is involved
in).
Redirect server: A redirect server receives requests from an entity, and returns the contact address of the destination to
the resquesting entity.
Registrar: The registrar processes registration requests; as a minimum this involves updating the users contact list and
responding to the originator of the request. Typically a registrar is co-located with either the proxy or the redirect server,
and may be adapted to perform location-based services.
SIP gateway: A SIP gateway acts as an interworking medium between the PSTN and a SIP network. It provides an
interworking between SIP and PSTN call control protocols, such as ISUP, as well as interworking between the TDM
and IP media flows. A SIP gateway can be decomposed into a gateway controller (taking cate of the call control
protocol conversion) and a media gateway (taking cate of the TDM to IP media conversion).
Figure 1 shows how the SIP functional elements map onto the functional layers in the IP Telephony Application plane.
Figure 1: Void
The UA maps to Service, Service Control (SC), Call Control (CC), and Bearer Control (BC) layers.
The statefull and stateless proxy maps to the TIPHON service control, call control and bearer layers.
The SIP gateway covers all TIPHON layers.
The redirect server works at TIPHON service control and call control layers.
The registrar works at TIPHON Service and Service Control layer.
Figure 2 shows the SIP entities and how they map to the functional layers and the Functional Groups (FG) defined in
TS 101 314 [1].
ETSI
12 ETSI TS 101 884-1 V4.1.1 (2003-08)
NFG
DNS
AAA
ENUM
IP Network services
S2, S3, A S3, A
S5 S5
TFG NFG GFG
SIP UA SIP
proxy
SIP
R1 R2
SIP
Registrar
Gateway
C1 C2 C2
S
SIP
C
Proxy
N
N3
M1/M2 Media
Gateway
M1 M2
NOTE 1: All entities in an IP network "normally" use the DNS service. In the context of the present document only
relations to the DNS with ENUM extensions are shown.
NOTE 2: The gateway shown is a decomposed gateway (combination of a gateway controller and a media
gateway).
Figure 2: SIP Architecture mapped to the TIPHON Functional layers and functional groups
The SIP proxy, SIP gateway and the SIP Registrar shall provide the functionality required in the Network Functional
Group (NFG). Reference point S2, S3 and A are between the Network Functional Group and other IP Network
S5
services e.g. DNS. The Network Functional Group may play the roles of an originating Network Functional Group, an
intermediate Network Functional Group or a terminating Network Functional Group.
NOTE: The Network Functional Group may include Media Control Functional Entities, e.g. for giving
announcements, mixing media streams etc. This is, however, out of scope of the present document.
The present document describes the mapping of functional architecture TS 101 314 [1], as well as the context,
behaviour and procedures TS 101 882-1 [5] that the SIP and SDP protocols must adhere to, to be TIPHON compliant.
In TIPHON Release 4, SIP is mapped to reference points R1, R2, C1, C2, where R1 and R2 refer to the registration
reference points, whereas C1 and C2 refer to call & bearer control reference points. The R and C reference points will
be dealt with separately in the present document, because of the different nature of services they provide.
6 Registration service
6.1 Introduction
According to the meta-protocol defined in TS 101 882-2 [6] and functional the description defined in TS 101 315 [2],
the purpose of the TIPHON registration service includes the authentication and authorization of a subscriber
(user/registrant) to access a service.
The basic registration mechanism can be described as follows:
1) User registration: The user registers for the service and shows entitlement for the service used.
2) Service preparation: The registrar selects a service node at which the user shall use the service and informs the
service node that the user is entitled to use the service.
3) Service attachment: The user (terminal) attaches to the service node and the service can be delivered.
ETSI
Service
Control
Services
Layer
Layer
Call
l
Contro
Layer
Bearer
ont
C rol
Layer
Media
Control
Layer
13 ETSI TS 101 884-1 V4.1.1 (2003-08)
Two registration scenarios shall be supported:
• the "User at home" scenario;
• the "Roaming user" scenario.
Registration in SIP is part of a location service. With the REGISTER message a UA informs location server how it
could be contacted. This functionality is a bit far from Registration service as defined in TIPHON. However, the
REGISTER message contains a Proxy-Authorization header field that allows an authentication and authorization
mechanism. This mechanism can be explicitly requested by the Service point of Attachment with a Proxy-Authenticate
header in a 407 (Proxy Authentication Required) Response. This field will be set by the UA and analysed by the Proxy
SpoA. RFE1 and RFE2 have to be the same SIP entity.
Consequently, there is not always a one to one mapping between TIPHON registration information flow sequence and
SIP registration signalling. For example the UA sends one or two REGISTER messages depending if the UA is waiting
for 401, 407 responses before setting Proxy-Authorization header. The REGISTER message will cover both
information flows Registration_req and Authorize_r. In case of "User at home" RFE2 and RFE3 can be considered as a
SIP outbound proxy and the REGISTER message is mapped with Registration_req and Authorize_req. In case of
"Roaming user" the REGISTER message will be forwarded by proxies that behave as Originating NFG and
intermediate FG to RFE2/RFE3. The initial REGISTER message shall contain information useful in both
Registration_req and Authorize_req and will be set by the UA.
Additionally, in case of "Roaming user", an intermediate proxy between RFE1 and RFE2 may require a SIP registration
from RFE1 before any TIPHON registration. This is implementation dependant. In pure IP environment RFE1 can
address directly its registration to RFE2 or has to go through an intermediate proxy. In both case it will have to know
the IP address, port and transport protocol of its home network. This can be done statically. The UA will have to know
also its current domain name address to set at its contact address.
De-Registration and Registration in SIP are covered by the same protocol message REGISTER.
According to RFC 3261 [9], chapter 22 "Basic" authentication is not allowed in SIP, only "Digest" authentication
mechanism described in RFC 2617 [13] overload by RFC 3261 [9] can be used. Authentication parameters value is
given in the following table for a "Digest" mode. Authentication parameters are given in unsuccessful message in SIP
while they are expected in successful message in TIPHON. This makes some distortion in the mapping.
Deregistration in SIP uses the same REGISTER message with the expire parameter set to zero on the contact to remove
or a contact list set to * (meaning all contact) and an Expires header field set to 0. The registrar cannot ask to the user
for deregistration.
ETSI
14 ETSI TS 101 884-1 V4.1.1 (2003-08)
A SIP registration signalling flow could be:
UA Regstrant Originating Network Intermediate Network Terminating Network Registrar/SpoA
SIP Terminal SIP outbound proxy SIP proxy SIP proxy SIP Proxy
REGISTER
407 Proxy Authentication required
REGISTER with
Proxy-Authorization: Value 1
200 OK
REGISTER
REGISTER forwarded
REGISTER forwarded
REGISTER forwarded
REGISTER with
Proxy-Authorization : Value 1
Proxy-Authorization : Value 2
REGISTER forwarded
REGISTER forwarded
REGISTER forwarded
200 OK
200 OK
200 OK
200 OK
Figure 3: The SIP registration example
6.2 Registration functional entities mapping
Table 1: Mapping of SIP entities to TIPHON Registration Functional entities
TIPHON functional element SIP entities
Identity TIPHON Description User at Home Roaming User
RFE1 Registrant, the logical entity being registered UA UA
RFE2 Registrar, holder of user profile of the Registrar Registrar
registrant
RFE3 Serving Service Provider point of Attachment Outbound Proxy Home Proxy
(SpoA)
RFE4 Previous SpoA Proxy Proxy

6.3 Registration Messages Mapping
Table 2 shows the mapping of TIPHON Registration meta-protocol information flows to SIP messages.
Responses to these requests, when a SIP message corresponds, are done with SIP responses described in RFC 3261 [9],
chapters 7.2 and 20. A 2XX answer corresponds to a positive answer while a 4XX-6XX answers to a reject.
ETSI
15 ETSI TS 101 884-1 V4.1.1 (2003-08)
Table 2: Mapping of SIP messages to TIPHON Registration MPMUs
TIPHON message RelationShip ID SIP messages
Register RFE1<->RFE2 REGISTER/SIP Response
DeRegister RFE1<->RFE2 REGISTER with contact header field set to * and Expires
header field set to 0/SIP Response
Authorize RFE2<->RFE3 None
Detach RFE2<->RFE3 None
Attach RFE3<->RFE1 Proxy-Authorization header field in SIP message concerned
by the service invocated
Detach RFE2<->RFE4 None
6.4 Registration information flow Mapping
6.4.1 Relationship ra (RFE1/RFE2)
Table 3: Mapping of SIP to Register request from RFE1 to RFE2
Register request/indication
TIPHON SIP
Information element Status Value Mapping Notes
TIPHON-reg-id M Any URI in the TO header TO and FROM SIP header
(address-of-record) can differ while for roaming
and username user scenario a third party
parameter in Proxy- Registration is needed
Authorization header
RegistrationMode M Initial registration None There is no distinction
Location update between Initial registration
and updating Contact in SIP
from data point of view.
Only behaviour requesting
the authorization (401, 407
Responses) can reflect a
first registration.
Location (of Registrant) M Contact header set to
the current location of
the registrant
protocolID  Fixed value 'sip' used
in addr-spec
nameorAddress  Name-addr or addr-
spec of Contact
port  Port of hostport of
addr-spec used in
Contact
ServiceName M TIPHON Simple Could be set as part
Call… of realm value in
Proxy-Authorization
header
ETSI
16 ETSI TS 101 884-1 V4.1.1 (2003-08)
Table 4: Mapping of SIP to Register response from RFE2 to RFE1
Register response/confirmation
TIPHON SIP
Information element Status Value Mapping Notes
TIPHON-reg-id M Any URI in the TO header
(address-of-record)
ServiceName O  None
(see note 2)
Result M Registration Status-Code 200 OK/407 Proxy
successful, Authentication require?,
Registration- 406 Not Acceptable, 503
Id invalid, Service Unavailable
Service
unavailable
ServiceProviderName O Any None
(see note 1)
ClientAuhorizationToken O Any Opaque parameter of (see note 1)
(see note 1) Proxy-Authenticate According to this note and
header note 3, there is no
mapping in flow sequence
NOTE 1: Provided if Result='Registration successful'.
NOTE 2: Provided if Result='Service unavailable'.
NOTE 3: This value will be present only 407 reject response.

Table 5: Mapping of SIP to DeRegister request from RFE1 to RFE2
DeRegister request/indication
TIPHON SIP
Information element Status Value Mapping Notes
TIPHON-reg-id M Any URI in the TO header
(address-of-record) and
username parameter in
Proxy-Authorization header
ServiceName M TIPHON Simple Could be set as part of realm
Call… value in Proxy-Authorization
header
Table 6: Mapping of SIP to DeRegister response from RFE2 to RFE1
DeRegistration response/confirmation
TIPHON SIP
Information element Status Value Mapping Notes
TIPHON-reg-id M Any URI in the TO header
(address-of-record)
Result M Deregistration Status-Code 200 OK, 406 Not
successful, Acceptable/407 Proxy
Registration-Id Authentication require?
invalid
ETSI
17 ETSI TS 101 884-1 V4.1.1 (2003-08)
6.4.2 Relationship rb (RFE2/RFE3)
Even if no SIP signalling flow is defined between RFE2 and RFE3 a pseudo mapping has been tried with the data
contains in the REGISTER message received by RFE2.
Table 7: Mapping of SIP to Authorize request from RFE2 to RFE3
Authorize request/indication
TIPHON SIP
Information element Status Value Mapping Notes
Registrar-id M Any Domain set in uri parameter
of Proxy-Authorization
header
TIPHON-reg-id M Any URI in the TO header
(address-of-record) and
username parameter in
Proxy-Authorization header
ServiceName M TIPHON Simple Could be set as part of
Call… realm value in Proxy-
Authorization header
Table 8: Mapping of SIP to Authorize response from RFE3 to RFE2
Authorize response/confirmation
TIPHON SIP
Information element Status Value Mapping Notes
Registrar-id M Any Domain set in domain note 1
parameter of Proxy-
Authenticate header
TIPHON-reg-id M Any URI in the TO header
(address-of-record)
ClientAuthorizationToken O Any Opaque parameter of notes 1 and 2 create a
(note 2) Proxy-Authenticate mismatch in the flow
header
Result M ServiceAuthorized to Status-Code 200 OK, 503 Service
Client, ResourceNot Unavailable
available
NOTE 1: This value will be present only 407 reject response and will have to be picked up before a successful
answer.
NOTE 2: This information element shall be provided if the value of Result is 'OK'.

Table 9: Mapping of SIP to Detach request from RFE2 to RFE3
Detach request/indication
TIPHON SIP
Information element Status Value Mapping Notes
Registrar-id M Any Domain set in uri parameter
of Proxy-Authorization header
TIPHON-reg-id M Any URI in the TO header
(address-of-record) and
username parameter in
Proxy-Authorization header
ServiceName M TIPHON Simple Call… Could be set as part of realm
value in Proxy-Authorization
header
ETSI
18 ETSI TS 101 884-1 V4.1.1 (2003-08)
Table 10: Mapping of SIP to Detach response from RFE3 to RFE2
Detach response/confirmation
TIPHON SIP
Information element Status Value Mapping Notes
Registrar-id M Any Domain set in domain (see note 1)
parameter of Proxy-
Authenticate header
TIPHON-reg-id M Any URI in the TO header
(address-of-record)
Result M Service detachment Status-Code 200 OK, 404 Not
successful Found/407 Proxy
Identity not recognized Authentication require?
NOTE 1: This value will be present only 407 reject response.
NOTE 2: This information element shall be provided if the value of Result is 'OK'.

6.4.3 Relationship rc (RFE1/RFE3)
The data are mapping only with the header field SIP Proxy-Authorization included in the SIP message correlated to the
service invocated.
Table 11: Mapping of SIP to Attach request from RFE2 to RFE3
Attach request/indication
TIPHON SIP
Information element Status Value Mapping Notes
Registrar-id M Any Domain set in uri
parameter of Proxy-
Authorization header
TIPHON-reg-id M Any username parameter
in Proxy-Authorization
header
ServiceName M TIPHON Simple Could be set as part of
Call… realm value in Proxy-
Authorization header
AuthorizationToken M Any Opaque parameter of
Proxy- Authorization
header
Table 12: Mapping of SIP to Attach response from RFE3 to RFE2
Attach response/confirmation
TIPHON SIP
Information element Status Value Mapping Notes
Registrar-id M Any None
TIPHON-reg-id M Any None Proxy-Authenticate header is
not sent in response when a
valid Proxy-Authorization has
been sent in the request
Result M Service attachment Status-Code 200 OK, 407 Proxy
successful Authentication require, None
Identity,
...