Individual
Internet Draft V. Mancuso
G. Teresi
L. Alcuri
F. Saitta
Document: draft-mancuso-qos-sua-00.txt University of Palermo
Italy
Category: Informational September 19, 2006
Expires: March 23, 2007
QoS-aware SIP User Agent operation in QoS-supporting networks
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 23, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the inter-working of a SIP (Session
Initiation Protocol) User Agent, SUA, located into a software
instance of a IP phone (Softphone), and a SIP Proxy located in the
access network where the user connects to Internet. The model
addressed is the one of a customer using a service offered by a
service provider, and the operation described only applies to the
negotiation and management of such kind of services. The network
architecture is supposed to be private, and the service provider is
Mancuso Expires - March 23, 2007 [Page 1]
QoS-aware SIP User Agent operation... September 2006
in charge to negotiate network resources with network provider(s) on
behalf of the customer, if necessary.
Aim of this draft is to highlight the need of inter-working functions
that allows service providers to use network-driven SIP messages to
establish and manage multimedia over IP connections.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................4
3. Private Access Domain IP Architecture..........................4
3.1 Service-oriented networking................................5
3.2 Resource management and reservation........................9
4. A QoS-aware SIP User Agent....................................17
4.1 QoS-aware SIP User Agent: definitions and functions.......18
4.2 QoS-aware SIP User Agent: actions.........................20
4.3 QoS-aware SIP User Agent: functional elements and functional
blocks........................................................20
4.4 Exploiting the SDP as in RFC 2327.........................21
4.5 SUA-assisted resource monitoring (usage of b= and ptime
selection)....................................................23
5. QoS-aware procedures..........................................24
5.1 Resource reservation......................................24
5.2 SUA initiated call setup..................................25
5.3 SUA terminated call setup.................................31
6. Messages description..........................................34
6.1 INVITE (generated by client SUA)..........................35
6.2 183 SESSION PROGRESS (generated by client SUA)............36
6.3 183 SESSION PROGRESS (generated by the local SIP Proxy)...37
6.4 PRACK (generated by the Client SUA).......................38
6.5 UPDATE (generated by the Client SUA)......................38
6.6 UPDATE (generated by the remote Client SUA)...............39
6.7 180 Ringing (generated by the remote Server SUA)..........40
6.8 ACK (generated by the Client SUA).........................40
6.9 CANCEL (generated by the Client SUA)......................40
6.10 487 REQUEST TERMINATED (generated by the remote Server SUA)40
7. Formal Syntax.................................................41
8. Security Considerations.......................................41
References.......................................................43
Acknowledgments..................................................44
Author's Addresses...............................................45
Full Copyright Statement.........................................45
1. Introduction
The use of SIP signalling [1] for the management of multimedia over
IP services has shown great potentialities and, in particular, SIP
has revealed great potentialities for the support QoS-aware operation
Mancuso Expires - March 23, 2007 [Page 2]
QoS-aware SIP User Agent operation... September 2006
in large and heterogeneous IP networks. However, in order to reach a
satisfactory level of quality experienced by users, a mere SIP
messaging exchange cannot satisfy certain minimal requirements if a
network support is not granted. In fact, the QoS and the robustness
of SIP-controlled multimedia connections is strongly affected by the
degree of integration between network operations and SIP
transactions. The interoperation with network entities aimed at
network management and traffic control (e.g. Softswitches, QoS
Servers, IMS entities) is needed at SIP level.
However, a full integration on network and SIP capabilities in not
feasible at User Agent level, both for security reasons and
computational load issues. Thus, we envision a proxy-based SIP
internetworking, where the SIP User Agent (SUA) contacts a designated
SIP Proxy whenever a connection has to be established with control of
QoS and robustness with respect to network changes, such as traffic
load variations.
The SIP Proxy SHOULD be capable of exchanging network control
messages with network entities that monitor the path between the
endpoints involved in the multimedia over IP session. In order to
accomplish this role, a SIP Proxy SHOULD be as closer as possible to
the SUA, i.e. in the access network, and it SHOULD have access the
resource manager of the access network. The SIP Proxy uses the
standard SIP protocol to contact remote networks and exchange control
messages.
Since network congestions and fast traffic load fluctuations are
typical issues for access networks and not for core networks, the
inter-working between SIP Proxy and access network management
entities represents the most important point to be tackled. In other
words, an efficient management of local resources, as obtained by a
counterbalanced use of SIP and low level traffic engineering methods,
allows service providers to confer QoS and robustness to multimedia
over IP services. Furthermore, the SUA can be made an active player
in the QoS control process by enforcing local resource control
functions that avoid the use of network resources in case of scarce
residual resources. Any piece of information obtained on the status
of the network (in particular, the status of the access network), and
on the status if the SUA, have to be mapped on a entry for the SIP
finite state machine running on SIP Proxy and SUA, in order to
determine the content of messages and methods used in the SIP
signalling between SIP Proxy and SUA.
In the envisioned framework, the main actors are represented by the
SIP user agent (in charge of local resource monitoring, and
supervision of customer premise equipment, CPE), and the SIP Proxy,
able to access network resource control entities in the access
network where the user is physically located. A description of the
operation performed by the SIP user agent and by the SIP Proxy will
be provided and discussed in relation to the resource control
operated by both user and proxy. A particularization of the use of
Mancuso Expires - March 23, 2007 [Page 3]
QoS-aware SIP User Agent operation... September 2006
SIP methods (including SIP extensions as defined in RFC3313[2]) will
be proposed throughout the document, jointly with a detailed
description of SIP message contents, and SDP fields in particular. In
fact, we will show that a basic support for the establishment and
management of multimedia over IP services with QoS support can be
provided by means of the use of bandwidth (b)and packet time (ptime)
attributes conveyed by the SDP, once the codec selection has been
performed.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3].
3. Private Access Domain IP Architecture
In the NGN networking progress, as a result of the definite move
toward IP, end-to-end policy enforcement coupled with IP QoS will be
used to prioritize complex and continuously changing traffic profiles
through the core and into the access networks.
Service providers, at least the ones who offer value-added services
to their customers, have at their disposal their own access networks
or, in alternative, they lease high-quality guaranteed network
connections to deploy their own services on top of those. Regarding
the core interconnection of remote access networks, current oversized
backbones make it possible to roughly neglect the effect of multiple
core networks on end-to-end services. At least, these consideration
holds for a first approximation analysis, or better when a service
provider exploits a suitable Service Level Agreement (SLA) that
describes the characteristics of a service offering and the mutual
responsibilities of the customers and providers for using and
providing the offered service. In particular, the SLA includes a
Service Level Specification (SLS) that denotes the technical
characteristics of a service offered, and may be used to agree on the
exchanging traffic at the border of two networks such as an access
network and a core or two cores managed by different owners.
Thus a private access network domain (or an access network with the
core managed by the same provider) represents the basic block to
deploy a service-oriented IP architecture, and it requires the
implementation of IP QoS mechanisms (i.e. traffic differentiation
methods like DiffServ [4] and MPLS [5], and per-flow and per-user
local policy enforcement, e.g. IntServ[6], RSVP [7] or TE-MPLS[8]).
Actually, a network domain that provides network access to customers
can be dealt with by separating the access network portion and the
core domain, which collects multiple access networks ad interconnects
Mancuso Expires - March 23, 2007 [Page 4]
QoS-aware SIP User Agent operation... September 2006
with multiple external domains. Thus, in what follows we will refer
to such a network domain as an access domain, since it allows
customers to access the network.
Note that lower layer mechanisms provided by technologies such as
xDSL and ATM, even if well suited to locally enforce controls and QoS
support, are not compliant with the end-to-end IP view of the
service, and it can also bring disadvantages when an extended QoS
requirement is considered. In fact, the local architecture, i.e. the
access domain IP architecture, SHOULD be given the opportunity to
negotiate and co-manage a broader policy function, in a end-to-end
perspective, no matter the local and remote technologies adopted.
Whereas IP offers the possibility to manage end-to-end policies in
heterogeneous network environments, the mapping between IP QoS and
lower technologies remains an open issue, and a trade off has to be
considered between flexibility of the mapping and expensiveness of
the adoption of multiple bearers at layer-2 (e.g. to map IP classes
over different ATM VCs).
3.1 Service-oriented networking
A network architecture able to support next-generation services with
QoS and robustness to network variations MUST be designed in order to
accomplish a minimal set of features in its access portion, such as
security, per-flow traffic control functionalities, per-user policy,
support for signalling protocols commonly adopted by user
applications (e.g., SIP[1][9], H323[10]) and inter-domain protocol
conversion as proposed in the IETF NSIS WG [11].
There are multiple layer-1 and layer-2 technologies that enable
service providers to support such features, but those technologies
are out of the scope of the present document. In any case, the
general IP architecture of the access network SHOULD be provided with
a proxy server (at last the proxy functionalities embedded in a
network control device, such as a BRAS or a DSLAM in a xDSL access
network [12][13]), and one or more border gateways. Furthermore, as
shown in figure 1, the access network can be provided with media
gateways – e.g. to allow ISDN/PSTN users to access VOIP services -,
and access routers – e.g. to permit the interconnection of LAN users
or WiFi hotspots -.
From the IP service point of view, the link technology adopted in the
access network has no relevance. Conversely, it is important to have
at disposal a “QoS Server” – either a centralized function or a
distributed mechanism in the overall managed IP domain – able to
handle the resources available in the access network.
In Figure 1, users are located in UE blocks (User Equipment), and
they can access the network with different technologies, including
Cable, DSL, PPP and Ethernet. Customer policy is controlled by the
QoS Server, who is also in charge of allotting specific resources for
specific connection requests. Regarding authentication and security,
Mancuso Expires - March 23, 2007 [Page 5]
QoS-aware SIP User Agent operation... September 2006
the QoS Server SHOULD include an AAA server, or be connected to a
higher-level AAA server located out of the access network.
Users SHOULD use the Proxy Server located in their access network to
access QoS-aware services; thus the Proxy Server represents the
Regional Service Access Point for customers.
At last, DB block represent the management database used by the QoS
server and any possible management functions.
More in deep, the availability of such blocks reflect the possibility
to logically decompose network functionalities into two main planes:
Service Control plane and Transport plane, as proposed in [14]:
. "Service Control Plane is composed of a set of functional
entities offering services under the control of service provider
which share a set of policies and common technologies."
. "Transport Plane is composed of a set of transport resources
sharing a common set of policies, QoS mechanism and transport
technologies under the control of a transport network operator."
+------------------------------------------+
/ +---------+ +----+ \
/ ACCESS | QOS | | DB | +---------+ \
/ NETWORK | SERVER | +----+ | IP |----------
/ +---------+ | | GATEWAY | \
/ \ | +---------+ +------
| +---------+ | +------+ | | \
+-------+ | | SIP | |/ \ | +---------+ \
| | \ | PROXY |----/ \-+ | MEDIA | |
| UE |--------+ +---------+ | \ | GATEWAY | |
| | \ \ | \ +---------+ |
+-------+ \ +--------+ / +----+ | |
\ | ACCESS | / NETWORK LINKS \ | /
\ | ROUTER |---/ (LAYER 2 PROVIDER)\--+ /
\ +--------+ | | /
+--------+ \ | | (IP, ATM, CABLE, / /
| | \ | \ DSL, SONET, ... ) / /
| UE |----+ \ / /
| | \ +-------------------+ /
+--------+ +------------ / -------- | ----------+
/ |
+-------+ +-------+
| | | |
| UE | | UE |
| | | |
+-------+ +-------+
Figure 1 – Access network with SIP features
Mancuso Expires - March 23, 2007 [Page 6]
QoS-aware SIP User Agent operation... September 2006
3.1.1 Control and Transport entities in NGN
Following definition given in [14], in a Next Generation Network
(NGN), control entities and transport entities of a network domain
are categorized as follows.
Regarding the Control Plane, five entities are in charge of managing
policies, customer access and interdomain traffic agreements:
. Policy Decision Function (PDF). It is a functional entity
residing in a network domain that maintains the policies of the
network provider. It is in charge of interfacing with the
Service Control plane and with PDFs of other domains. It also
decides if inter-domain SLA can be applied and enforces policies
to transport resources by the Border Gateway Functions and the
Access Gateway Functions in order to achieve specified QoS
levels.
. Network Resource DataBase Function (NRDBF). It is the entity
that measures and collects all the information useful for QoS
and resource management procedures in a network domain.
. Access Control Function (ACF). It is a functional entity
residing in a network domain that performs QoS and resource
management procedures and applies decisions and policies to
transport resources, i.e. the Access Gateway Functions and to
the IP Edge Functions in the Access Transport Network, to enable
specified QoS levels to be achieved.
. Core Control Function (CCF). It is a functional entity residing
in a network domain that performs QoS and resource management
procedures and applies decisions and policies to transport
resources to the Core network to achieve specified QoS levels.
. Border Control Function (BCF). It is a functional entity
residing in a network domain that decides if interdomain SLA
setup by PDF can be applied and enforces policies to transport
resources to the Border Gateway Functions to enable specified
QoS levels to be achieved.
As for the transport plane, the entities that represent the nodes of
a traffic flow within an access network are the following:
. Access Node (AN): is the element in charge of interfacing the UE
with its network domain.
. IP Edge Function (IEF): is the first IP element between the user
and the IP network. Its main functionalities cover packet
merging, opening gates, usage metering.
. Access Gateway Function (AGF): is located between the access
network and the core network. Its main functionalities encompass
per-flow packet merging, opening gates, traffic policing,
resource allocation and bandwidth reservation, NAPT-PT, usage
metering.
Mancuso Expires - March 23, 2007 [Page 7]
QoS-aware SIP User Agent operation... September 2006
Two additional function are given to support access to core and core
to core transport:
. Core Transport Function (CTF): The CTF is a functional entity
representing the collection of transport resources within a
Network Domain, which is capable of QoS control.
. Border Gateway Function (BGF): is located between two core
networks, which could be owned by different network operators.
Its main functionalities include per-aggregate packet merging,
opening gates, traffic policing, resource allocation and
bandwidth reservation, NAPT-PT, usage metering.
Control and Transport entities are the means to deploy a QoS-aware
networking in the scope of an IP domain, while SLA and SLS represent
the tool to extend QoS networking to multidomain communications.
Regarding an end-to-end multidomain path, the effectiveness of the
QoS networking can be obtained by means of domain-to-domain
signalling and end-to-end control protocols to be enforced in
elements such as gateways and proxies.
3.1.2 Proxy Servers and Gateways
The Proxy Server plays the role of the QoS-enabled services gate. It
allows customers to request services within their own service
agreement. The Proxy Server functionality permits to decouple
service-level operation and network-level operation, and it makes
transparent to the customer the management of local access network
resources.
The Proxy Server is an IP device to be contacted by the customer in a
given access network, before to access the Access Gateway Function.
Thus the Proxy Server SHOULD be provided with a standard signalling
protocol to be used by customers and with one or more protocols to
access QoS Server functions.
Furthermore the Proxy Server duty is to contact and to be contacted
by remote parts on behalf of the local user. So, using Proxy Servers
also for incoming connections, provides a way to manage the QoS of
offered services, no matter where they are originated.
Regarding the physical deploying of the Proxy Server, a possibility
is that the Proxy Server is a stand alone machine, or also that it is
located within a SSW or a gateway.
At the edge of a network domain, e.g. at the edge of the access
domain, a border gateway SHOULD be deployed with the task of
enforcing domain policies, on a per-packet basis, and operates as a
NAT/NAPT as a consequence of management decisions taken by the QoS
Server. The border gateway is the last IP device in an access domain
and it is connected to foreign networks, so it is involved in the
resource allocation and bandwidth reservation procedures with a
twofold role: to communicate resources available at the node and to
Mancuso Expires - March 23, 2007 [Page 8]
QoS-aware SIP User Agent operation... September 2006
estimate resources available in the link towards the remote part of
the communication path.
At the customer access point, the border gateway is replaced by an
access gateway (e.g. an IP DSLAM in DSL networks, or an access
router), with similar policy functionalities regarding the traffic
produced by customers.
3.1.3 The QoS Server
The QoS Server is the network element that has to provide the service
logic necessary to take the decisions regarding the resource
availability to grant the degree of quality required. To provide
these functionalities the QoS server has to be developed with
specific characteristics, particularly granting a high reliability
and a high speed in the decisions.
To map the functionalities into requirements, two types of “internal”
functions are assumed:
. The FEF (Front-End Function), for QoS Servers that interface
external elements (e.g. another QoS Server) and are able to
route AC requests.
. The ACF (Admission Control Function), which is a function that
keeps track of the topology information and resource allocation
for one or more access networks, and applies the AC algorithm to
accept or reject an AC request. A QoS Server can have zero or
more ACF, in particular a QoS Server can consist of a FEF alone,
in this case it does not provide an AC decision itself but only
a reference point to send AC requests to, and route the request
elsewhere.
The QoS Server, in this architecture, makes policy decisions based on
policy set-up information obtained from proxies and gateways via the
specific interface:
. the QoS Server SHOULD check if the information received is
consistent;
. it Authorizes QoS resources for each session, based on the
information received about bandwidth and authorization;
. the QoS Server SHOULD be able to enforce the right behaviour to
other network elements in the access domain;
. the QoS Server SHOULD manage QoS authorization and its update,
when needed due to a mid-call media or codec change;
. the QoS SERVER SHOULD revoke the QoS resource at session
release;
. the QoS Server MUST be able to manage token procedure.
3.2 Resource management and reservation
Centralized network control is often deployed by means of a SSW
platform, which is particularly suited to separate network hardware
and software, and also network functionalities.
Mancuso Expires - March 23, 2007 [Page 9]
QoS-aware SIP User Agent operation... September 2006
Another control solution is based on the IP Multimedia Subsystem
(IMS), where the SIP protocol has been firstly proposed and tested to
handle signalling within IP packets and heterogeneous network
domains.
With reference to issues related to resource management and resource
reservation in IP networks, in this section we presents the most
relevant features of both SSW-based and IMS-based architectures.
Anyway, we do not give any insight in the protocol suite adopted to
fulfil reservation and management tasks.
3.2.1 Networking with SoftSwitch
The SSW is a platform meant to perform network control at flow level
in a given access domain. It is designed to centrally manage a lot of
services and access technologies.
Typical SSW task are:
. Session and Call Control for IP users (SIP, H.323 and MGCP);
. SIP Proxy/Registrar;
. Call Control for traditional TDM users by means of Access
Gateway (AGW) controlled via H.248/IUA and/or Access Node (AN)
via V5.x;
. Interconnection with IP PBX (H.323, SIP) and/or traditional PBX
(PRI) (Enterprise users);
. Supplementary Telephony Services for the “legacy users” (H.323,
MGCP, PRI, V5.x, H.248/IUA);
. Media Gateway Controller (MGC);
. Generation of CDR (for billing and documentation) for any kind
of calls;
. Lawful Interception;
. Interconnection with other IP domains (H.323, SIP);
. Interconnection with PSTN/PLMN (Embedded Signalling Gateway –
SG), possibility also to interconnect external SGW by means of
the M3UA/SCTP (SIGTRAN) protocol;
. Interconnection with Service Layer (SIP, H.323 and/or INAP based
elements)
The SSW is composed of a Legacy Subsystem plus a SIP Session Server,
which is devoted to Session control for SIP users.
The Legacy Subsystem supports telephony and value added services,
offered both to TDM and IP (H.323, MGCP) users, either in public or
in private network domains. It also performs the Media Gateway
Controller functionalities of the network.
The SIP Session Server is both a SIP Proxy and a SIP Registrar. The
SIP Proxy performs routing functions that are characteristic of SIP
end-to-end connections, and it is the only outbound proxy for all the
signalling burden generated or needed by a set of SIP users.
Regarding the SIP Registrar, it is the entity in charge of acquiring
user profiles and authentication information; the SIP Registrar
Mancuso Expires - March 23, 2007 [Page 10]
QoS-aware SIP User Agent operation... September 2006
operates authentication and registration and it also provides
location service.
Furthermore, the SSW is also a Session Handling Server which
interacts with network databases to get user profiles, to operate
authentication of session requests, to control the user contract
status (type of contract, type of outgoing traffic qualification,
user in bad payer status, user under interception, etc.), to detect
emergency calls, and to handle services subscribed by users (and the
associate billing) and requiring the establishment of a session. For
services which do not need a session (e.g. text messaging), the SSW
act as a non-session handling server, with the same functionalities
(database interconnection, authentication of request, user contract
control, detecting and handling of services).
3.2.2 Reservation and QoS management Procedures with IMS
In the envisioned framework of service convergence towards IP, the IP
Multimedia Subsystem (IMS) has been proposed [15]. The IMS is a
technology that defines how to set up advanced services, and it has
been initially thought for 3G cellular networks. It offers a flexible
vehicle for deploying new applications by exploiting the IP
architecture of the underlying network with a considerably potential
revenue-generation. The IMS enables a service provider to deliver
identical IP services to fixed and mobile customers, both in case the
destination is an IP network or a circuit-switched network. Services
built on top of IMS enable communications in a variety of modes, such
as voice, video, text, pictures and combinations of these, and it
operates a personalization of services whereas supporting security
and confidentiality. More in deep, the IMS is a media-over-IP network
characterized as follows:
. it uses SIP for default signalling;
. it is based on IP technologies;
. it is able to provide all-IP services;
. it allows connection to packet-switched networks and to circuit-
switched networks;
. it is an architecture for service and call control;
. it provides flexible multimedia services everywhere and every
time;
. it easily support customer’s roaming for nomadic and mobile
applications;
. it is designed to be flexible, robust and secure;
. it allows faster service creation and cost-effective service
deployment;
. it is a convergent network for any type of services.
The main goals of IMS is to support real-time IP-based multimedia
communication services, such as voice over IP and video conferencing.
Since all services will use IP, another goal of IMS is to provide the
ability for interaction between services, so that users may combine
Mancuso Expires - March 23, 2007 [Page 11]
QoS-aware SIP User Agent operation... September 2006
different services in one session, for example, voice and
whiteboards.
As previously stated, the IMS has been envisioned to be used for any
mobile access technology; however, due to its independence from the
network access layer, it can be seen as the next generation service
delivery platform framework for any kind of network where SIP is an
integral part of this framework.
Regarding the architecture, IMS proposes a service architecture based
on a collection of logical functions that can be divided into three
layers as shown in figure 2: Access, Control and Service.
+--------------------------------------------+
| |
Service | IMS-SSF AS PCF |
Layer | OSA-SCS PDF |
| SIP-AS PEP |
| |
+--------------------------------------------+
Control | |
Layer | MRFP MRFC +-----------+ |
| | Databases | |
| BGCF | | |
| | BS HSS | |
| I-CSCF S-CSCF +-----------+ |
| |
+--------------------------------------------+
Access | |
Layer | P-CSCF T-SGW |
| MGCF MGW |
| |
+--------------------------------------------+
Figure 2 - IP Multimedia Subsystem Overview
The Access Layer initiates and terminates signalling to setup
sessions and provides bearer services between the endpoints. It
contains a Proxy Server which is specialized for SIP signalling.
Media gateways are provided to convert from/to analogical/digital
voice telephony formats to/from IP packets using the Real Time
Protocol (RTP). IMS signalling is based on the Session Initiation
Protocol (SIP), and works on top of IPv4 and IPv6. The main entities
in this layer are:
. P-CSCF. The Proxy Call Session Control Function is the first
contact point for users within the IMS. All SIP signalling
traffic from or to the user crosses the P-CSCF. The P-CSCF
behaves like a SIP Proxy as defined in [1]. In addition, the P-
CSCF may behave as a SIP User Agent as defined in [1] to deal
Mancuso Expires - March 23, 2007 [Page 12]
QoS-aware SIP User Agent operation... September 2006
with releasing of sessions upon a bearer failure and for
generating independent SIP transactions aiming at registration
issues.
. T-SGW. The Transport Signalling Gateway serves as the PSTN
signalling termination point and provides PSTN/legacy mobile
networks to IP transport level address mapping, which maps call-
related signalling from PSTN on an IP bearer and sends it to the
MGCF, and vice versa.
. MGCF. The Media Gateway Control Function is a gateway that
enables communication between IMS and Circuit Switched (CS)
users. All incoming call control signalling from CS users is
destined to the MGCF that performs protocol conversion between
the ISDN User Part (ISUP), or the Bearer Independent Call
Control (BICC), and SIP protocols and forwards the session to
IMS. In similar fashion all IMS-originated sessions toward CS
users traverses MGCF.
. MGW. The Media Gateway is in charge of the interworking among CS
networks and IP based networks. It converts the format of the
data coming from TDM based networks to the IP based networks
data format.
The second layer is the Control layer, meant to deal with centralized
session control and central policy management. The control elements
are in charge of providing the communications control, referring to
establishment, modification and session ending. CSCF is present also
in this layer of the IMS architecture to enable the registration of
devices or endpoints and the routing of SIP signalling messages to
the appropriate server. CSCF also interworks with network access and
transport layers to guarantee QoS across all services. The Control
layer additionally includes the Home Subscriber Server (HSS) database
that maintains the unique service profile for each end-user. By
centralizing user information, applications can share information to
create unified personal directories, multi-client type presence
information and blended services. The main entities in this layer
are:
. S-CSCF. The Serving-CSCF is the central node of the signalling
plane. It is a SIP server, but performs session control and
registration services for users as well. It is always located in
the home network. S-CSCF maintains a session state for each user
connection and interacts with service platforms and charging
functions as needed by the network operator for supporting
services. It also provides routing services and enforces the
policy of the network operator.
. I-CSCF. The Interrogating-CSCF is a contact point within an
operator's network for all connections destined to a subscriber
of that network operator. It is a SIP Proxy and there may be
multiple I-CSCFs within an operator's network. Its main
functions are to contact the HSS to obtain the name of the S-
CSCF that is serving a user and to forward SIP requests or
Mancuso Expires - March 23, 2007 [Page 13]
QoS-aware SIP User Agent operation... September 2006
responses to the S-CSCF. It can also be used to hide the
internal network from the outside world.
. MRFC. The Multimedia Resource Function Controller is needed to
support bearer-related services, such as conferencing,
announcements to a user or bearer transcoding. The MRFC
interprets SIP signalling received via S-CSCF and uses the Media
Gateway Control Protocol (MEGACO) instructions to control the
MRFP.
. MRFP. The Multimedia Resource Function Processor (MRFP) provides
user-plane resources that are requested and instructed by the
MRFC. The MRFP operates the mixing of media streams (e.g., for
multiple parties), and media stream processing (e.g., audio
transcoding) and can also generate media streams source for
multimedia announcements.
. BGCF. The Breakout Gateway Control Function is a SIP server that
includes routing functionality based on telephone numbers. It is
only used for the interworking between IMS and CS networks.
. HSS. The Home Subscriber Server is the main database for
subscribers and services in the IMS: it stores user identities,
registration information, access parameters and service-
triggering information. IMS access parameters are used to set up
sessions and include parameters like user authentication,
roaming authorization and allocated S-CSCF names. Service-
triggering information enables SIP service execution. The HSS
also provides user-specific requirements for S-CSCF
capabilities. This information is used by the I-CSCF to select
the most suitable S-CSCF for a user.
. BS. The Billing System is the charging system. It collects,
stores and processes the needed information for a fair charging.
The third layer is the Service layer, which provides network
independent applications, integrated web portals and support for
real-time communications. IMS architecture enables devices and
application servers to send their session initiation request through
a common CSCF. The CSCF interacts with the access and transport
networks to assess current traffic levels and can deny requests for
additional sessions when the network threatens to become overloaded.
The access elements in charge of providing the access to every
communication occurred in a IMS system are:
. AS. The Application Server hosts and executes services, and
interfaces with the S-CSCF using SIP. An AS may be dedicated to
a single service and a user may have more than one service,
therefore there may be one or more ASs per subscriber.
Additionally, there may be one or more ASs involved in a single
session. There are three types of application servers:
o SIP AS (Session Initiation Protocol AS): it interworks
directly with S-CSCF.
Mancuso Expires - March 23, 2007 [Page 14]
QoS-aware SIP User Agent operation... September 2006
o OSA AS (Open Service Architecture AS): it uses the OSA-SCS
gateway (OSA Sevice Capability Servers) to contact the S-
CSCF.
o CAMEL AS (Customized Application Mobile Enhanced Logic AS).
This AS uses the IP Multimedia Service Switching Function
(IM-SSF) to reach the S-CSCF.
. Policers (PDF, PCF, PEP). These are functions and entities
dedicated to the QoS handling as described in what follows.
The QoS management is obtained through three entities: the Policy
Decision Function (PDF), the Policy Control Function (PCF) and the
Policy Enforcement Point (PEP). PDF interacts with and controls the
underlying packet network and provides it with the relevant
information for each service to allow the network to control the
resources that the service uses. These controls prevent any service
from stealing resources from another service. PCF is triggered by
user requests (i.e. SIP requests) requiring a particular QoS profile:
PCF retrieves the network policy rules from a Policy Repository to
see whether the request can be granted or not. If the request can be
granted, the PCF translates the policy rules into specific
configuration actions for a QoS mechanism and sends them to the PEP,
which actually implements the QoS mechanisms. It is worth noting that
this procedure decouples the policies of the network from the
specific mechanisms used to achieve them.
When the PCF decides to accept a request, it also creates an
authorization token that is sent to the SIP user. This token will be
used to authenticate the user at PEP side and to allow the user to
access the specifically reserved set of resources and to allow
packets to reach the appropriate GGSN node with the appropriate QoS
labelling.
IP SIP signalling
+---------------------------------------------+
| |
| +--------------+ |
+-----+ | | Go +-----+ Gq +--------+
| UE |---| PEP --- GGSN |------| PDF |------| P-CSCF |
+-----+ | | | +-----+ +--------+
+----------|---+
|
-----
/ \
-- ------------
/ OUTER IP NETWORK \
\ /
---------------------
Figure 3 – 3GPP-like access domain architecture
Mancuso Expires - March 23, 2007 [Page 15]
QoS-aware SIP User Agent operation... September 2006
The interface between the PDF and GGSN, named Go interface, supports
the transfer of information and policy decisions. The PDF makes
policy decisions based on information obtained from the AF. It maps
the policy setup information from the AF via the Gq interface [16]
into IP QoS parameters.
The architecture proposed by the 3GPP, with the key elements and the
reference points, is shown in Figure 3, where the P-CSCF is located
in the same access domain of the GGSN.
3.2.3 Media negotiation with SIP
With the IP policy control operated by means of the SIP protocol, it
is possible to authorize and control the usage of bearer traffic
intended for multimedia applications. SIP can be used in both SSW
architectures and IMS, where it is required the interaction between
the IP connectivity access network and the IMS.
In fact, SIP allows to perform an end-to-end media negotiation by
means of IP packets handled by users and SIP Proxies which can be
located in the SSW as well as in the CSCF in a IMS.
During media negotiation two SIP users agree on the set of media they
want to use for the session and which codecs will be used for the
different media types.
Therefore, the SDP offer/answer mechanism [17] is used, which — in
the IMS — basically works in the following way (also sketched in
Figure 4):
1. The calling user sends a first SDP offer in the INVITE request to
the called user. This SDP lists all media types (e.g., audio,
video or certain applications like whiteboard or chat) the caller
wants to use for this session and lists the different codecs that
the caller supports for encoding these different media types.
2. The called user responds with a first SDP answer, in which it may
reject some of the proposed media types. It also reduces the list
of codecs by ignoring those that it does not support, such that
only the codecs that are supported on both sides remain.
3. After receiving the first answer the caller has to make the final
decision on the used codecs. It sends a second offer to the
called user, which indicates a single codec for every media type
that will be used during the session.
4. The called user accepts the second offer and sends an answer back
as confirmation.
SIP allows media connections to be set up after just one offer/answer
exchange. In the IMS the selection of a single codec per media stream
enforces a second exchange, if the first SDP answer includes more
than one codec for any media type. This is done because both lots of
user must be prepared to receive any of the selected codecs and,
therefore, would need to reserve resources on the air interface for
Mancuso Expires - March 23, 2007 [Page 16]
QoS-aware SIP User Agent operation... September 2006
the codec with the higher bandwidth, despite maybe using the codec
with the lower bandwidth throughout the session.
User A User B
| SIP INVITE (SDP A) – First offer |
|--------------------->--------------------|
| |
| SIP 183 SESSION PROGRESS (First answer) |
|---------------------<--------------------|
| |
| |
| SIP PRACK (SDP B) – Second offer |
|--------------------->--------------------|
| |
| SIP 200 OK (Second offer) |
|---------------------<--------------------|
| |
Figure 4 - Media negotiation flow in IMS
4. A QoS-aware SIP User Agent
The User Equipment signalling part of a SIP Scenario is commonly
referred to as SIP User Agent (SUA). A SUA SHOULD provide QoS aware
functionalities, and it MUST provide basic (non QoS-aware)
functionalities. Then the SUA SHOULD be provided with SIP extension
for the resource management, according the results of IETF [2],[9],
but at the same time has to work in a not QoS aware scenario, without
SIP extensions. In particular, in order to support QoS-aware
operation, the SUA SHOULD provide additional information about the
resource consumption, such as the packetization time used for the
codec, and the bandwidth requirements.
Next generation IP-based User Equipment will include SIP User Agents
with enhanced capabilities which includes audio, video and multimedia
devices to be accessed by a single software tool. These Softphones
will be endowed with a user-friendly interface that permits a simple
management of the software [18]. The fundamental modules of the
software are [19]:
. the Control Center, which is the kernel of the Softphone and
represents the trait-d’union between all other software modules;
. the GUI, i.e. the user interface with graphical capabilities;
. the Multimedia Handling Tools Module, which manages I/O devices
for audio video and multimedia support;
. the SIP User Agent, which operates (extended) SIP signalling.
Mancuso Expires - March 23, 2007 [Page 17]
QoS-aware SIP User Agent operation... September 2006
Furthermore, two additional modules are devoted to the interaction
with hardware devices, and they are fundamental as for local
monitoring of resources:
. the I/O Hardware, that offers a set of API’s for the management
of microphone, speakers, webcams, keyboards and any other
multimedia I/O tools;
. the Network Hardware, that handles the connection to physical
Network Card(s), and that provides statistics about protocols
and packets at the network interface(s).
4.1 QoS-aware SIP User Agent: definitions and functions
A SIP User Agent with QoS enhancement is a 3GPP- and SIP- compliant
SIP User Agent, which is provided with QoS-oriented features.
When interactive applications have to be dealt with (as in the case
of VoIP applications or, more in general, audio/video/text and
interactive graphic applications), this SUA is in charge of
triggering and managing the signalling between end-users and between
network and customers. The SUA operates via the SIP protocol defined
by RFC 3261 [1] and its standard extensions necessary to support the
QoS enhancement. SIP defines the way a session has to be labelled and
identified, using the mandatory header fields Via, From, To, CSeq,
and Call-Id that uniquely identify a transaction, and a set of
optional field that are available for advanced signalling operation.
Moreover, application-level signalling data are conveyed by the SDP
protocol, which is tunnelled through the payload of SIP messages. The
SDP payload can transport many parameters, such as codecs to be
adopted in the data flow exchange, bandwidth that should be reserved
over the end-to-end communication path, characteristics of the
service requested by the caller, and traffic parameters such as the
mean data rate, the peak data rate, the maximum burst size of each
source, minimum and maximum allowed size of data segments to be
transmitted. Summarizing, the QoS-aware SUA can be thought as:
1. An entity that manages the basic connection between call-
originating and call-terminating parties;
. it handles SIP signalling at CPE;
. it allows IP telephony;
. it allows Video over IP;
. it allows real-time multimedia data exchange over IP;
. it manages multiple service-classes;
2. An entity that triggers SIP and SDP protocols;
. initiates/terminates signalling;
. manages signalling;
. fills call-originating SDP payload;
. read call-terminating SDP payload;
. negotiates SDP parameters;
. refreshes SIP Finite State Machine;
Mancuso Expires - March 23, 2007 [Page 18]
QoS-aware SIP User Agent operation... September 2006
3. An entity that interact with user’s applications for remote
connection.
4. A software that interacts with IP devices in the access network
(SIP Proxy, for QoS-aware operation)
5. A software that interacts with remote users (UA-UA, for direct
connection, without QoS guarantees).
Furthermore, the key features of a QoS-aware SIP UA we are aiming at,
can be resumed in the following list:
1. Carrier-Class Performance: the SUA MUST support high call
throughput, while utilizing low memory per call and maximizing
the system reliability. Multiple classes SHOULD be differentiated
in the signalling exchange, and negotiation SHOULD be allowed
before the beginning of the connection and during the connection
itself (dynamic renegotiation).
2. Support of all SIP Methods: the SUA MUST be compliant with the
standard SIP methods: INVITE, ACK, CANCEL, REGISTER, BYE,
OPTIONS, SUBSCRIBE, NOTIFY and INFO. The UA SHOULD also provide
extensibility to support new and user-defined methods, i.e. PRACK
and UPDATE methods.
3. Support of media gateways (SIP Telephony): the SUA COULD allow
the exchange of signalling information between media gateway
controllers.
4. Security: security issues, such as digest authentication and
authorizing functions, interaction with automatic firewalls
SHOULD be provided.
5. Legacy Internet protocol support: transport protocols to be
supported are the legacy TCP and UDP from the TCP/IP suite. The
network protocol is the standard IP, in which the Record-Route
option SHOULD be activated to admit path-oriented end-to-end
signalling and data-flows. Furthermore, a Multi-Part MIME support
MUST be granted in order to allow the MIME encoding of messages.
6. Conformance to RFC 3312 [9]: “Integration of Resource Management
and Session Initiation Protocol (SIP)”. This RFC introduces the
concept of a precondition that is a set of constraints about the
session which are introduced in the SDP body of a SIP messages
and are sent from the caller endpoint to the answerer endpoint.
The recipient of the offer generates an answer, which contains
information about its media capabilities without alerting the
user or otherwise proceeds with session establishment.
7. Conformance to RFC 3313 [2]: “Private Session Initiation Protocol
(SIP) Extensions for Media Authorization”. That document defines
a SIP extension that can be used to integrate QoS admission
control with call signalling and help guard against denial of
service attacks.
8. Conformance to RFC 3262 [20]: “Reliable Provisional Response in
Session Initiation Protocol (SIP)”. Support for RSeq and RAck and
PRACK method; support for Session Header and 183 Response for
Caller Telephony Interaction.
Mancuso Expires - March 23, 2007 [Page 19]
QoS-aware SIP User Agent operation... September 2006
9. Conformance to RFC 3264 [21]: “offer/answer model with Session
Description Protocol (SDP)”. This document defines a simple
offer/answer model based on SDP. In this model, one participant
in the session generates an SDP message that constitutes the
offer - the set of media streams and codecs the offerer wishes to
use, along with the IP addresses and ports the offerer would like
to use to receive the media. The offer is conveyed to the other
participant, called the answerer. The answerer generates an
answer, which is an SDP message that responds to the offer
provided by the offerer.
4.2 QoS-aware SIP User Agent: actions
In order to obtain such a behaviour the SUA:
. maps user-level services into network parameters and codecs;
. drives A/V software at CPE;
. drives text-based tools (messaging) at CPE;
. drives drawing-based tools at CPE;
. drives users’ hardware (e.g., via OSS or ALSA);
. interacts with RTP/RTCP protocols;
. interacts with remote User Equipments (B2BUA, Back-to-back UA)
. interacts with SSW in the access network (i.e., with the SIP
Proxy) in order to perform:
o User Agent registration;
o User Agent session establishment;
o User Agent session tear down;
4.3 QoS-aware SIP User Agent: functional elements and functional blocks
According to RFC 3261 [1], the SUA functional elements are:
. SIP User Agent Client. It generates a request based on some
external stimulus and processes a response.
. SIP User Agent Server. It is capable of receiving a request and
generating a response.
Functional elements are composed by functional blocks, which are:
. Transaction Manager: the block that handles the four types of
Finite State Machines (FSM) correspondents at the four types of
transaction defined in [1]; the transaction may be handled also
in a multithread mode in order to handle contemporarily more
than one session.
. SIP Message Handler: the functions of this block are in charge
of the SIP messages generation and the messages parsing. Other
functions, then, are in charge of the mapping between messages
and correspondent transactions.
. SDP Parser: the functions of this block parse the SDP messages
in order to obtain information about the media session, to be
passed to the other modules.
Mancuso Expires - March 23, 2007 [Page 20]
QoS-aware SIP User Agent operation... September 2006
. Connection Handler: this functional block parses the network
parameters and handles the Transport connections necessary to
send and receive the SIP messages.
4.4 Exploiting the SDP as in RFC 2327
SDP, described in [17] is a session description protocol for
multimedia sessions. The purpose of SDP is to convey information
about media streams in multimedia sessions to allow the recipients of
a session description to participate in the session.
SDP contains the following basic information about the media session:
. IP Address (IPv4 address or host name);
. Port number (used by UDP or TCP for transport);
. Media type (audio, video, interactive whiteboard, and so forth);
. Media encoding scheme (PCM A-Law, MPEG II video, and so forth).
. Subject of the session;
. Start and stop times;
. Contact information about the session.
SDP uses text coding, and SDP messages are composed by a set of
mandatory and optional fields, whose names are abbreviated by a
single lower-case letter. For sake of simplicity, a set of SDP fields
of interest is shown in the following table 1.
The optional b= field contains information about the bandwidth
required. It is of the form:
b=<modifier>:<bandwidth-value>
The modifier value can be either CT (in order to summarize a
conference total bandwidth), or AS (for application specific
information). CT is used for multicast session to specify the total
bandwidth that can be used by all participants in the session. AS is
used to specify the bandwidth of a single site. The bandwidth-value
parameter is the specified number of kilobytes per second. This field
could be used to directly inform the SSW about the bandwidth
requested for a multimedia session. For codecs defined in IANA [22],
the b= field is redundant and can be omitted. Instead, for other
codecs, has to be written by the UA in the SDP field.
The a= field defines the attributes of the media. It is used to
extend SDP: in fact it is the only way of doing so. Attributes can be
session-level attributes, media-level attributes or both. Attribute
interpretation depends on the media tool being invoked.
Its syntax is as follows:
a=<attribute field>
a=<attribute field>:<attribute value>
Mancuso Expires - March 23, 2007 [Page 21]
QoS-aware SIP User Agent operation... September 2006
Attributes may be defined to be used as "session-level" attributes,
"media-level" attributes, or both.
An extension that SHOULD be used to allow QoS-aware operation of the
SUA is the ptime attribute, defined in the Draft-ietf-mmusic-sdp-new
[23] and summarized in Table 2.
Possible values for ptime are 10, 15, 20, 30, 40 (milliseconds), so
that an example of usage of ptime, combined with the specification of
a media is as follows:
m=audio 49170 RTP/AVP 97
a=ptime:20
---------------------------------------------------------
Field Name Usage
---------------------------------------------------------
v= Protocol version number mandatory
o= Owner/creator and session identifier mandatory
s= Session name mandatory
i= Session information optional
U= Uniform Resource Identifer optional
e= Email address optional
p= Phone number optional
c= Connection information mandatory
b= Bandwidth information optional
t= Time session starts and stops mandatory
r= Repeat times optional
z= Time zone corrections optional
k= Encryption key optional
a= Attribute lines optional
m= Media information optional
a= Media attributes optional
---------------------------------------------------------
Table 1: partial SDP Field List in their required order [17]
--------------------------------------------------------------------
Name Attribute line Description
--------------------------------------------------------------------
Packet time a=ptime:<packet time> It represents the media
content length conveyed by
one packet, expressed in
milliseconds. It is just a
recommendation and is not
necessary to be used when
decoding RTP
--------------------------------------------------------------------
Table 2: partial SDP Field List in their required order
Mancuso Expires - March 23, 2007 [Page 22]
QoS-aware SIP User Agent operation... September 2006
In the above example the m-line defines the audio media name and
transport address, plus a list of codec (in this case only one codec,
labelled as 97), while the packet time if set to 20 millisecond by
the a-line.
4.5 SUA-assisted resource monitoring (usage of b= and ptime selection)
The b= and a=ptime lines are fundamental since the actual bandwidth
consumption due to the use of a codec results from the combination of
codec rate and packet overhead. The code rate is conveyed in the b-
line, while the overhead should be computed by means of the packet
time defined in a=ptime.
Both SUA and SIP Proxy SHOULD consider the composition of b-line and
packet time attribute to figure out the actual amount of resource
needed in the reservation process. Unfortunately, with a packet time
of the order of 10 milliseconds, the protocol overhead is quite
sensible, and it grows with the compactness of the encoded stream.
However, while the computation of UDP, TCP and IP protocols is
straightforward, the impact of layer-2 mechanisms is more difficult
to compute, especially at user side.
Regarding QoS-aware procedures, the SUA SHOULD perform bandwidth
monitoring at user side, so to exploit bandwidth and packet time
information received within SIP messages. Bandwidth consumption
estimate SHOULD consider at least the overhead due to network and
higher layers protocols (e.g. IP, UDP and RTP).
In case or resource scarcity, the SUA SHOULD try to negotiate a
longer packet time value before to change the codec set. As an
example, using a G711 codec for audio over RTP with 20 milliseconds
packet time requires 64 Kbps of neat bandwidth plus 16 Kbps due to
IP, UDP and RTP overhead; using a ptime=10 milliseconds the overhead
grows up to 32 Kbps.
It is worth noting that the scarcity of resources at customer
premises can be detected by the SUA by monitoring the traffic at
network interface. When the SUA detect a congestion status and, it
COULD try to recover from the congestion by updating session
parameters with SIP UPDATE messages [24]: a good choice would be to
firstly try to augment the packet time value without changing the
codec in use.
Mancuso Expires - March 23, 2007 [Page 23]
QoS-aware SIP User Agent operation... September 2006
5. QoS-aware procedures
In this section we describe the adaptation of SIP methods and
messages to obtain a signalling meant to perform QoS-aware resource
management and in particular resource reservation.
5.1 Resource reservation
The network SHOULD be provided with a QoS Server which authorizes,
reserves and commits the resources necessary for each session. In
fact, network QoS-related procedures are initiated by a SIP Proxy
request to the QoS Server, which then sends a response to the SIP
Proxy.
If the network architecture adopts a SSW, the QoS Server could be
located within the SSW or connected to the SSW via proprietary
interfaces and protocols. On the contrary, in case of IMS, the QoS
Server MUST be contacted via IP, and it SHOULD be part of the policy
decision function (PDF), e.g. located in a GGSN.
When the resource reservation procedure successes, an authorization
token can be produced and notified to the SUA as an additional header
of a SIP message generated or modified by the SIP Proxy.
If QoS resource procedure fails, the QoS Server can’t authorize
reservation and commitment of resources necessary for the new session
and thus it sends a negative response to the SIP Proxy.
The QoS reservation decisions for the access network are based on two
criteria, resources and policy. Regarding the resource criterion, it
is simply checked whether the network has enough capacity to accept a
requested call or not. For the policy resource decisions must be made
locally at the policy enforcement point within the access network.
Policy decision can be more centralized, typically located within a
SSW. The rationale of this choice is that the SSW is the closest SIP
point of contact for the SUA within the access network.
The SIP Proxy contacts the SSW upon the reception of the following
messages:
. the first 183 SESSION PROGRESS message generated by a Client SUA
located in its access network;
. the first 183 SESSION PROGRESS message generated by a Server SUA
located in its access network.
At that point end-users had already agreed the CODEC, the bandwidth
(b= attribute), and the packet time (a=ptime attribute).
Thus the SSW is able to check if resource in the access network
enough are available in the access network.
As soon as the resources are reserved and committed the SSW generates
an authorization token. The value of the token is inserted in the
header of a SIP message sent by the SIP Proxy to the SUA in the
access network. In case of a call originated in the access network,
Mancuso Expires - March 23, 2007 [Page 24]
QoS-aware SIP User Agent operation... September 2006
the SIP Proxy SHOULD use the additional header in the 183 SESSION
PROGRESS messages originated by the callee part, the same messages
used to trigger the reservation procedure. Differently, in case of
call terminated in the access network, the SIP Proxy SHOULD add the
token as a P-Media-Authorization header in the UPDATE messages
generated by the remote caller part as a reply to the 183 SESSION
PROGRESS and the following PRACK exchange.
The failure of a reservation procedure SHOULD be notified to the SUA
by means of a SIP message. When the call is originated in the access
network, the SIP Proxy can use the 183 SESSION PROGRESS message with
a void token as additional header. Conversely, when the call is
terminated in the access network of the SIP Proxy, a simple CANCEL
method SHOULD be sent to the local SUA (Server SUA).
However, the use of the additional P-Media-Authorization header can
be avoided if the SSW considers any resource request automatically
committed, or if the access network resource management is stateless.
When a token is conveyed to the SUA, these SHOULD be used to commit
the reserved resources. Similarly, the token SHOULD be used by the
SIP Proxy to release resources at the close of each SIP session.
5.2 SUA initiated call setup
This is an example of the call-flow triggered by SUA (as client user
agent) in the originating access network, during a session setup. A
remote callee (which can be either a remote SUA - as server user
agent – or a media gateway) will be located in a remote access
network, not shown in figures, with its SIP Proxy. Moreover,
multiple SIP Proxy could be traversed by SIP messages. Messages
coming from the rightmost part of the figure are assumed to be
originated by that remote user (or by the media gateway).
Case a)
Call setup with reservation operated by SIP Proxy with positively
acknowledged reservation.
Mancuso Expires - March 23, 2007 [Page 25]
QoS-aware SIP User Agent operation... September 2006
+-------+ +-------+
| C-SUA | | Proxy |
+-------+ +-------+
| |
| (1) INVITE(100rel, SDP ‘A’) |
|----------------->---------------|
| | (2) INVITE(100rel, SDP ‘A’)
| |---------------->------------
| |
| |(3)183 SESSION PROG. (SDP‘B’)
| |----------------<------------
| |
| | (4) Resource Request
| |---------------->------------
| |
| | (5) Reservation (ACCEPTED)
| |----------------<------------
| (6) 183 SESSION PROGRESS |
| (SDP ‘B’) |
|-----------------<---------------|
| |
| (7) PRACK |
|----------------->---------------|
| | (8) PRACK
| |---------------->------------
| |
| | (9) 200OK(PRACK)
| |----------------<------------
| (10) 200OK(PRACK) |
|-----------------<---------------|
| |
| (11) UPDATE(SDP ‘C’) |
|----------------->---------------|
| | (12) UPDATE(SDP ‘C’)
| |---------------->------------
| |
| | (13) 200OK(UPDATE)
| |----------------<------------
| (14) 200OK(UPDATE) |
|-----------------<---------------|
| |
| | (15) 180RINGING
| |----------------<------------
| (16) 180RINGING |
|-----------------<---------------|
| |
| (17) PRACK |
|----------------->---------------|
(...)
Mancuso Expires - March 23, 2007 [Page 26]
QoS-aware SIP User Agent operation... September 2006
(...)
| | (18) PRACK
| |---------------->------------
| |
| | (19) 200OK(PRACK)
| |----------------<------------
| (20) 200OK(PRACK) |
|-----------------<---------------|
| |
| | (21) 200OK(INVITE)
| |----------------<------------
| (22) 200OK(INVITE) |
|-----------------<---------------|
| |
| (23) ACK
|----------------->-------------------------------->------------
Case b)
Call setup with reservation operated by SIP Proxy and Token with
positively acknowledged reservation.
In this case, a token is used in the 183 SESSION PROGRESS.
+-------+ +-------+
| C-SUA | | Proxy |
+-------+ +-------+
| |
| (1) INVITE(100rel, SDP ‘A’) |
|----------------->---------------|
| | (2) INVITE(100rel, SDP ‘A’)
| |---------------->------------
| |
| | (3)183 SESSION PROGRESS
| | (SDP ‘B’)
| |----------------<------------
| |
| | (4) Resource Request
| |---------------->------------
| |
| | (5) Reservation (ACCEPTED)
| |----------------<------------
| |
| (6) 183 SESSION PROGRESS |
| (SDP ‘B’,TOKEN) |
|-----------------<---------------|
| |
| (7) PRACK |
|----------------->---------------|
(...)
Mancuso Expires - March 23, 2007 [Page 27]
QoS-aware SIP User Agent operation... September 2006
(...)
| | (8) PRACK
| |---------------->------------
| |
| | (9) 200OK(PRACK)
| |----------------<------------
| (10) 200OK(PRACK) |
|-----------------<---------------|
| |
| (11) UPDATE(SDP ‘C’) |
|----------------->---------------|
| | (12) UPDATE(SDP ‘C’)
| |---------------->------------
| |
| | (13) 200OK(UPDATE)
| |----------------<------------
| (14) 200OK(UPDATE) |
|-----------------<---------------|
| |
| | (15) 180RINGING
| |----------------<------------
| (16) 180RINGING |
|-----------------<---------------|
| |
| |
| (17) PRACK |
|----------------->---------------|
| | (18) PRACK
| |---------------->------------
| |
| | (19) 200OK(PRACK)
| |----------------<------------
| (20) 200OK(PRACK) |
|-----------------<---------------|
| |
| | (21) 200OK(INVITE)
| |----------------<------------
| (22) 200OK(INVITE) |
|-----------------<---------------|
| |
| (23) ACK
|----------------->-------------------------------->------------
Case c)
Call setup with reservation operated by SIP Proxy with refused
reservation (no token).
Mancuso Expires - March 23, 2007 [Page 28]
QoS-aware SIP User Agent operation... September 2006
+-------+ +-------+
| C-SUA | | Proxy |
+-------+ +-------+
| |
| (1) INVITE(100rel, SDP ‘A’) |
|----------------->---------------|
| | (2) INVITE(100rel, SDP ‘A’)
| |---------------->------------
| |
| |(3)183 SESSION PROG. (SDP‘B’)
| |----------------<------------
| |
| | (4) Resource Request
| |---------------->------------
| |
| | (5) Reservation (REJECTED)
| |----------------<------------
|(6) 183 SESSION PROGR. (SDP ‘B’) |
|-----------------<---------------|
| |
| (7) PRACK |
|----------------->---------------|
| | (8) PRACK
| |---------------->------------
| |
| | (9) 200OK(PRACK)
| |----------------<------------
| (10) 200OK(PRACK) |
|-----------------<---------------|
| |
| (11) CANCEL |
|----------------->---------------|
| | (12) CANCEL
| |---------------->------------
| |
| | (13) 200OK(CANCEL)
| |----------------<------------
| (14) 200OK(CANCEL) |
|-----------------<---------------|
| | (15) 487REQUEST TERMINATED
| |----------------<------------
| (16) 487REQUEST TERMINATED |
|-----------------<---------------|
| |
| (17) ACK
|----------------->-------------------------------->------------
Case d)
Call setup with reservation operated by SIP Proxy with refused
Mancuso Expires - March 23, 2007 [Page 29]
QoS-aware SIP User Agent operation... September 2006
reservation (with token in 183 SESSION PROGRESS).
+-------+ +-------+
| C-SUA | | Proxy |
+-------+ +-------+
| |
| (1) INVITE(100rel, SDP ‘A’) |
|----------------->---------------|
| | (2) INVITE(100rel, SDP ‘A’)
| |---------------->------------
| |
| |(3)183 SESSION PROG. (SDP‘B’)
| |----------------<------------
| |
| | (4) Resource Request
| |---------------->------------
| |
| | (5) Reservation (REJECTED)
| |----------------<------------
| (6) 183 SESSION PROGRESS |
| (SDP ‘B’, token=void) |
|-----------------<---------------|
| |
| (7) PRACK |
|----------------->---------------|
| | (8) PRACK
| |---------------->------------
| |
| | (9) 200OK(PRACK)
| |----------------<------------
| (10) 200OK(PRACK) |
|-----------------<---------------|
| |
| (11) CANCEL |
|----------------->---------------|
| | (12) CANCEL
| |---------------->------------
| |
| | (13) 200OK(CANCEL)
| |----------------<------------
| (14) 200OK(CANCEL) |
|-----------------<---------------|
| |
| | (15) 487REQUEST TERMINATED
| |----------------<------------
| (16) 487REQUEST TERMINATED |
|-----------------<---------------|
| (17) ACK
|----------------->-------------------------------->------------
Mancuso Expires - March 23, 2007 [Page 30]
QoS-aware SIP User Agent operation... September 2006
5.3 SUA terminated call setup
These are examples of the call-flow triggered by a remote SUA (as
client user agent) in the remote access network, during a session
setup.
Case a)
Call setup with reservation operated by SIP Proxy with positively
acknowledged reservation (no token used).
+-------+ +-------+
| Proxy | | S-SUA |
+-------+ +-------+
| |
(1) INVITE(100rel, SDP ‘A’) | |
-------------->---------------| |
| (2) INVITE(100rel, SDP ‘A’) |
|---------------->---------------|
| |
|(3) 183 SESSION PROG. (SDP ‘B’) |
|----------------<---------------|
(4) Resource Request | |
--------------<---------------| |
| |
(5) Reservation (ACCEPTED) | |
-------------->---------------| |
| |
(6) 183 SESSION PROG. (SDP ‘B’)| |
--------------<---------------| |
| |
(7) PRACK | |
-------------->---------------| |
| (8) PRACK |
|---------------->---------------|
| |
| (9) 200OK(PRACK) |
|----------------<---------------|
(10) 200OK(PRACK) | |
--------------<---------------| |
| |
(11) UPDATE(SDP ‘C’) | |
-------------->---------------| |
| (12) UPDATE(SDP ‘C’) |
|---------------->---------------|
| |
| (13) 200OK(UPDATE) |
|----------------<---------------|
(...)
Mancuso Expires - March 23, 2007 [Page 31]
QoS-aware SIP User Agent operation... September 2006
(...)
(14) 200OK(UPDATE) | |
--------------<---------------| |
| (15) 180RINGING |
|----------------<---------------|
(16) 180RINGING | |
--------------<---------------| |
| |
(17) PRACK | |
-------------->---------------| |
| (18) PRACK |
|---------------->---------------|
| |
| (19) 200OK(PRACK) |
|----------------<---------------|
(20) 200OK(PRACK) | |
--------------<---------------| |
| |
| (21) 200OK(INVITE) |
|----------------<---------------|
(22) 200OK(INVITE) | |
--------------<---------------| |
| |
(23) ACK |
-------------->-------------------------------->---------------|
Case b)
Call setup with reservation operated by SIP Proxy with positively
acknowledged reservation (with token carried by SIP UPDATE).
+-------+ +-------+
| Proxy | | S-SUA |
+-------+ +-------+
| |
(1) INVITE(100rel, SDP ‘A’) | |
-------------->---------------| |
| (2) INVITE(100rel, SDP ‘A’) |
|---------------->---------------|
| |
| (3)183 SESSION PROGR. (SDP‘B’) |
|----------------<---------------|
| |
(4) Resource Request | |
--------------<---------------| |
| |
(5) Reservation (ACCEPTED) | |
-------------->---------------| |
(...)
Mancuso Expires - March 23, 2007 [Page 32]
QoS-aware SIP User Agent operation... September 2006
(...)
| |
(6) 183 SESSION PROG. (SDP‘B’)| |
--------------<---------------| |
| |
(7) PRACK | |
-------------->---------------| |
| (8) PRACK |
|---------------->---------------|
| |
| (9) 200OK(PRACK) |
|----------------<---------------|
(10) 200OK(PRACK) | |
--------------<---------------| |
| |
(11) UPDATE(SDP ‘C’) | |
-------------->---------------| |
| (12) UPDATE(SDP ‘C’, Token) |
|---------------->---------------|
| |
| (13) 200OK(UPDATE) |
|----------------<---------------|
(14) 200OK(UPDATE) | |
--------------<---------------| |
| |
| (15) 180RINGING |
|----------------<---------------|
(16) 180RINGING | |
--------------<---------------| |
| |
(17) PRACK | |
-------------->---------------| |
| (18) PRACK |
|---------------->---------------|
| |
| (19) 200OK(PRACK) |
|----------------<---------------|
(20) 200OK(PRACK) | |
--------------<---------------| |
| |
| (21) 200OK(INVITE) |
|----------------<---------------|
(22) 200OK(INVITE) | |
--------------<---------------| |
| |
(23) ACK |
-------------->-------------------------------->---------------|
Mancuso Expires - March 23, 2007 [Page 33]
QoS-aware SIP User Agent operation... September 2006
Case c)
Call setup with reservation operated by SIP Proxy with denied
reservation.
In this case, no need of token usage arises. In fact, the QoS Served
does not provide ant token and the Server SUA receives a CANCEL
message to abort the connection attempt (or, as an alternative, the
procedure could go on without reservation and QoS support).
+-------+ +-------+
| Proxy | | S-SUA |
+-------+ +-------+
| |
(1) INVITE(100rel, SDP ‘A’) | |
-------------->---------------| |
| (2) INVITE(100rel, SDP ‘A’) |
|---------------->---------------|
| |
| (3)183 SESSION PROGRESS |
| (SDP ‘B’) |
|----------------<---------------|
(4)183 SESSION PROGRESS | |
(SDP ‘B’) | |
--------------<---------------| |
| |
(5) Resource Request | |
--------------<---------------| |
| |
(6) Reservation (REJECTED) | |
-------------->---------------| |
| |
| (7) CANCEL |
|---------------->---------------|
| |
| (8) 200OK(CANCEL) |
|----------------<---------------|
| |
| (9) 487REQUEST TERMINATED |
|----------------<---------------|
(10) 487REQUEST TERMINATED | |
--------------<---------------| |
| |
(11) ACK |
-------------->-------------------------------->---------------|
6. Messages description
This section provides further remarks and specifications about the
usage of SIP messages with QoS-aware extensions.
Mancuso Expires - March 23, 2007 [Page 34]
QoS-aware SIP User Agent operation... September 2006
6.1 INVITE (generated by client SUA)
The Client SUA determines the complete set of codecs that it is
capable of supporting for this session. It builds a SDP containing
bandwidth requirements and characteristics of the connection, and
assigns local port numbers for each possible media flow. Multiple
media flows may be offered, and for each media flow (“m=” SDP line),
multiple codec choices might be offered. In order to support the QoS
negotiation with precondition in the message the “Require” header is
set with the precondition value and to support the reliability of a
provisional response the “Supported” header is set with the 100rel
value.
For instance, in the following message example it is assumed that the
Client SUA is willing to establish a multimedia session comprising a
video stream and an audio stream. The video stream supports two
codecs and the audio stream supports only one codec. Client UA sends
the INVITE request, containing an initial SDP, to the SSW. The
following code defines the INVITE message sent by the Client SUA.
INVITE sip:userB@unipa.it SIP/2.0
Via: SIP/2.0/UDP 10.163.57.156:1357
Max-Forwards: 70
From: <sip:userA@unipa.eu>;tag=171828
To: < sip:userB@tti.unipa.it >
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 INVITE
Require: precondition
Supported: 100rel
Contact: <sip:10.163.57.156:1357 >
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 10.163.57.156
s=-
c=IN IP4 10.163.57.156
t=0 0
m=video 3400 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 H263
a=rtpmap:99 MP4V-ES
a=fmtp:98 profile-level-id=0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
Mancuso Expires - March 23, 2007 [Page 35]
QoS-aware SIP User Agent operation... September 2006
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:97 AMR
a=rtpmap:96 telephone-event
6.2 183 SESSION PROGRESS (generated by client SUA)
The media stream capabilities of the destination are returned along
the signalling path, in a 183 Session Progress provisional response
to the local SIP Proxy.
In a SSW environment, upon receiving the 183 SESSION PROGRESS, the
local SIP Proxy knows the media flow information about this session
and sends this information to the QoS Server via the Gq interface in
order to perform the resources reservation.
In IMS case the 183 SESSION PROGRESS generated by the client SUA is
sent to the P-CSCF to ask the opening of gate at local PEP/GGSN.
The 183 SESSION PROGRESS message looks like the following:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP proxy.unipa.it;branch=z9hG4bK431h23.1, SIP/2.0/UDP
10.163.57.156:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To: <sip:user@tti.unipa.it>;tag=314159
Call-ID:
CSeq:
Require: 100rel
Contact: <sip:10.167.23.16:8805;comp=sigcomp>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
RSeq: 9021
Content-Type: application/sdp
Content-Length: (...)
v=0
o=- 2987933623 2987933623 IN IP4 10.167.23.16
s=-
c=IN IP4 10.167.23.16
t=0 0
m=video 10001 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=rtpmap:98 H263
a=rtpmap:99 MP4V-ES
a=fmtp:98 profile-level-id=0
Mancuso Expires - March 23, 2007 [Page 36]
QoS-aware SIP User Agent operation... September 2006
m=audio 6544 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
6.3 183 SESSION PROGRESS (generated by the local SIP Proxy)
This message can contain a P-Media Authorization header, which holds
the media authorisation token. Upon the receipt of the media
authorisation token, the SUA generates a flow identifier which
identifies an IP media flow associated with the SIP session. The Flow
Identifiers are based on the sequence of media flows in the SDP. A
Flow Identifier combined with the authorization token is sufficient
to uniquely identify an IP media flow.
All field of the message are leaved blank.
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
10.163.57.156:1357;comp=sigcomp;branch=z9hG4bKnashds7
P-Media-Authorization:
0020000100100101706466312e686f6d65312e6e6574000c02013942563330373200
From:
To:
Call-ID:
CSeq:
Require:
Contact:
Allow:
RSeq:
Content-Type:
Content-Length:
v=
o=
s=
c=
t=
m=
b=
a=
a=
a=
a=
Mancuso Expires - March 23, 2007 [Page 37]
QoS-aware SIP User Agent operation... September 2006
a=
a=
a=
a=
m=
b=
a=
a=
a=
a=
a=
a=
a=
a=
6.4 PRACK (generated by the Client SUA)
The Client SUA determines which media flows should be used for the
session, and which codecs should be used for each of those media
flows. If there was any change in media flows, or if there was more
than one choice of codec for a media flow, then Client SUA includes a
new SDP offer in the PRACK request sent to remote Server SUA through
the SIP Proxy.
6.5 UPDATE (generated by the Client SUA)
When the resource reservation is completed, the Client SUA sends the
UPDATE request to the terminating endpoint, via the signalling path
established by the INVITE request. The request is sent first to the
SIP Proxy.
UPDATE sip: 10.167.23.16:8805;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP
10.163.57.156:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
From:
To:
Call-ID:
Cseq: 129 UPDATE
Content-Type: application/sdp
Content-Length: (...)
v=0
o=- 2987933615 2987933617 IN IP4 10.163.57.156
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=video 3400 RTP/AVP 98
b=AS:75
Mancuso Expires - March 23, 2007 [Page 38]
QoS-aware SIP User Agent operation... September 2006
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
6.6 UPDATE (generated by the remote Client SUA)
When the resource reservation is completed, the remote Client SUA
sends the UPDATE request to the terminating endpoint, via the
signalling path established by the INVITE request. The request is
sent first to the SIP Proxy, which is in charge to add the P-Media-
Authorization header containing the token to be used by the local
Server SUA to commit resources.
UPDATE sip: 10.167.23.16:8805;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP
10.163.57.156:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Media-Authorization:
0020000100100101706466312e686f6d65312e6e6574000c02013942563330373200
From:
To:
Call-ID:
Cseq: 129 UPDATE
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933617 IN IP4 10.163.57.156
s=-
c=IN IP6 5555::aaa:bbb:ccc:ddd
t=0 0
m=video 3400 RTP/AVP 98
b=AS:75
a=curr:qos local sendrecv
a=curr:qos remote none
Mancuso Expires - March 23, 2007 [Page 39]
QoS-aware SIP User Agent operation... September 2006
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
m=audio 3456 RTP/AVP 97 96
b=AS:25.4
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
6.7 180 Ringing (generated by the remote Server SUA)
The called SUA (even when located on a media gateway) may optionally
perform alerting. If so, it alerts the calling party by means of a
180 Ringing provisional response towards the Client SUA. This
response is sent first to the local SIP Proxy.
6.8 ACK (generated by the Client SUA)
The Client SUA starts the media flow for this session, and responds
to the 200OK with an ACK request sent to the local SIP Proxy.
6.9 CANCEL (generated by the Client SUA)
The SUA cancels the original INVITE request. Alternatively the SUA
can continue the session setup without assuring an adequate QoS
level, and the media flow will be treated as a best effort traffic.
CANCEL sip: 10.167.23.16:8805;comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP
10.163.57.156:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
From: <sip:userA@unipa.eu>;tag=171828
To: <sip:userB@tti.unipa.it>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 1 CANCEL
Content-Length: 0
6.10 487 REQUEST TERMINATED (generated by the remote Server SUA)
The termination procedure cancels the request, and returns a SIP
error response to the original INVITE request.
SIP/2.0 487 Request Terminated
Mancuso Expires - March 23, 2007 [Page 40]
QoS-aware SIP User Agent operation... September 2006
Via: SIP/2.0/UDP proxy.unipa.it;branch=z9hG4bK332b23.1, SIP/2.0/UDP
10.163.57.156:1357;comp=sigcomp;branch=z9hG4bKnashds7
From:
To:
Call-ID:
CSeq: 127 INVITE
Content-Length: 0
7. Formal Syntax
This document syntax uses the augmented Backus-Naur Form (BNF) as
described in RFC-2234 [25].
8. Security Considerations
The SUA is meant to be ready to dialogue with a QoS-aware SIP Proxy,
able to perform the setup, maintenance and tear down of calls and
resources, and also able to manage AAA procedures in a transparent
way.
The SUA is the end-point of the session service architecture, and is
bound to a SIP Proxy, whatever the access network adopted for the
physical connectivity between SUA and Proxy.
In order to access a service, a user needs to be registered by means
of a SIP registration procedure, as shown in the following message
exchange. The registration requires a digest authentication with
username and password, but our proposed approach requires a double
exchange of information in order to perform a secure authentication,
as described in the following.
a) REGISTER without digest (initial registration request)
• The SUA sends a SIP REGISTER containing the user URI only;
• The Proxy replies with a 401 – Unauthorized message, in which
it is specified the required authentication method: the field
WWW-Authenticate contains the method “Digest”, the “realm”
name, and the value of the field “nonce”, to be used for the
computation of a “response” string by means of the MD5
encrypting algorithm;
b) REGISTER with digest (as a consequence of the unauthorized
request)
• The SUA computes the “response” string and sends it to the
proxy as a field of a new SIP REGISTER message;
• If the “response” field received by the proxy from the UA is
equal to the output of the MD5 algorithm performed on the proxy
with the same set of data (username, password, realm, nonce,
SUA’s URI, SIP method = REGISTER), the proxy will send a 200OK
message and the user is authenticated and registered.
Mancuso Expires - March 23, 2007 [Page 41]
QoS-aware SIP User Agent operation... September 2006
The registration procedure within a SIP domain id sketched in the
following message exchange:
+-----+ +-------+
| SUA | | Proxy |
+-----+ +-------+
| |
| (1) REGISTER (no digest auth.) |
|----------------->-----------------|
| |
| (2) 100 TRYING |
|-----------------<-----------------|
| |
| (3) 401 UNAUTHORIZED |
|-----------------<-----------------|
| |
| |
| |
| (4) REGISTER (with digest auth.) |
|----------------->-----------------|
| |
| |
| (5) 100 TRYING |
|-----------------<-----------------|
| |
| (6) 200 OK |
|-----------------<-----------------|
| |
The content of REGISTER messages, as used in the above scheme, i.e.
respectively without and with digest authentication, is reported
here jointly with a typical 401- Unauthorized response:
REGISTER without digest authentication:
REGISTER sip:10.163.57.48 SIP/2.0
To: <sip:6274@10.163.57.48>
From: <sip:6274@10.163.57.48>;tag=a8bd703b
Via: SIP/2.0/UDP 10.163.57.41:5060;branch=z9hG4bK-d87543-
b0ae88146920ef55-1--d87543-;rport
Call-ID: 87cbbc59e4568d6a@RXVjbGlkZS50dGkudW5pcGEuaXQ.
CSeq: 1 REGISTER
Contact: <sip:6274@10.163.57.41>
Expires: 3600
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
User-Agent: SUA v.-1.1-beta
Mancuso Expires - March 23, 2007 [Page 42]
QoS-aware SIP User Agent operation... September 2006
Content-Length: 0
REGISTER without digest authentication:
REGISTER sip:10.163.57.48 SIP/2.0
To: <sip:6274@10.163.57.48>
From: <sip:6274@10.163.57.48>;tag=a8bd703b
Via: SIP/2.0/UDP 10.163.57.41:5060; branch=z9hG4bK-d87543-
4d5eef6b4f003c2e-1--d87543-;rport
Call-ID: 87cbbc59e4568d6a@RXVjbGlkZS50dGkudW5pcGEuaXQ.
CSeq: 2 REGISTER
Contact: <sip:6274@10.163.57.41>
Expires: 3600
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
User-Agent: SUA v.-1.1-beta
Authorization: Digest username="6274", realm="asterisk",
nonce="35534d5c", uri="sip:10.163.57.48",
response="e8f01145c9a58d792666d7fd5fa34efa", algorithm=MD5
Content-Length: 0
The SIP Proxy response to REGISTER without digest authentication is
as follows:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.163.57.41:5060;branch=z9hG4bK-d87543-
b0ae88146920ef55-1--d87543-
From: <sip:6274@10.163.57.48>;tag=a8bd703b
To: <sip:6274@10.163.57.48>;tag=as42d9741d
Call-ID: 87cbbc59e4568d6a@RXVjbGlkZS50dGkudW5pcGEuaXQ.
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:6274@10.163.57.48>
WWW-Authenticate: Digest realm="asterisk", nonce="35534d5c"
Content-Length: 0
References
[1] J. Rosenberg et al., “SIP: Session Initiation Protocol”, RFC
3261, June 2002
[2] W. Marshall, “Private Session Initiation Protocol (SIP)
Extensions for Media Authorization”, RFC 3313, January 2003
[3] S. Bradner, “Key words for use in RFCs to Indicate Requirement
Levels”, RFC 2119, March 1997
[4] K. Nichols, “Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998
[5] E. Rosen, “Multiprotocol Label Switching Architecture”, RFC
Mancuso Expires - March 23, 2007 [Page 43]
QoS-aware SIP User Agent operation... September 2006
3031, January 2001
[6] R. Braden, “Integrated Services in the Internet Architecture:
an Overview”, RFC 1633, September 1994
[7] S. Shenker, “Specification of Guaranteed Quality of Service”,
RFC 2212, September 1997
[8] R. Zhang, “MPLS Inter-Autonomous System (AS) Traffic
Engineering (TE) Requirements”, RFC4216, November 2005
[9] G. Camarillo, “Integration of Resource Management and Session
Initiation Protocol (SIP)”, RFC 3312, October 2002
[10] ITU-T Raccomandation H.323 : Packet-based multimedia
communications systems
[11] R. Hancock, “Next Steps in Signaling (NSIS): Framework”,
RFC4080, June 2005
[12] Technical Report, DSL Forum TR-039, “Requirements for Voice
over DSL, Version 1.1”, March 2001
[13] Technical Report, DSL Forum TR-059, “DSL Evolution –
Architecture Requirements for the Support of QoS-Enabled IP
Services”, September 2003
[14] ETSI TS 282 001: "NGN Functional Architecture”
[15] IP Multimedia Subsystems (IMS) Forum, http://www.imsforum.org
[16] 3GPP TS 23.002 v6.1.0 “Network architecture (Release 6)”
[17] M. Handley, “SDP: Session Description Protocol”, RFC 2327,
April 1998
[18] The CELTIC IMAGES project. Official web site:
http://projects.celtic-initiative.org/IMAGES
[19] http://projects.celtic-initiative.org/IMAGES/detailed_WP4.htm
[20] J. Rosenberg, H. Schulzrinne, “Reliability of Provisional
Responses in the Session Initiation Protocol (SIP)”, RFC 3262,
June 2002
[21] J. Rosenberg, H. Schulzrinne, “An Offer/Answer Model with the
Session Description Protocol (SDP)”, RFC 3264, June 2003
[22] http://www.iana.org/assignments/wave-avi-codec-registry
[23] M. Handley et al, Internet-Draft: draft-ietf-mmusic-sdp-new-
25.txt, July 16, 2005
[24] J. Rosenberg, “The Session Initiation Protocol (SIP) UPDATE
Method”, RFC 3311, September 2002
[25] D. Crocker, and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
Acknowledgments
The work presented in this draft has been carried out by the
Telecommunication group of the Faculty of Engineering at University
of Palermo, Italy. The work has been co-funded by the European
Community and by the Italian Government in the frame of the IMAGES
project, within the cluster of European project belonging to the
CELTIC initiative.
Mancuso Expires - March 23, 2007 [Page 44]
QoS-aware SIP User Agent operation... September 2006
Author's Addresses
Comments are solicited and should be addressed to the authors.
Vincenzo Mancuso
DIEET, University of Palermo
9, Viale delle Scienze, 90128 Palermo, Italy
Phone: +39 091 6615 274
Email: vincenzo.mancuso@tti.unipa.it
Giuseppe Teresi
DIEET, University of Palermo
9, Viale delle Scienze, 90128 Palermo, Italy
Phone: +39 091 6615 273
Email: giuseppe.teresi@tti.unipa.it
Luigi Alcuri
DIEET, University of Palermo
9, Viale delle Scienze, 90128 Palermo, Italy
Phone: +39 091 6615 250
Email: luigi.alcuri@tti.unipa.it
Francesco Saitta
DIEET, University of Palermo
9, Viale delle Scienze, 90128 Palermo, Italy
Phone: +39 091 6615 269
Email: francesco.saitta@tti.unipa.it
Full Copyright Statement
Copyright (C) The Internet Society (2006). All Rights Reserved.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into.
Mancuso Expires - March 23, 2007 [Page 45]
QoS-aware SIP User Agent operation... September 2006
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Mancuso Expires - March 23, 2007 [Page 46]