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=: 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= a=: 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: 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: ;tag=171828 To: < sip:userB@tti.unipa.it > Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 1 INVITE Require: precondition Supported: 100rel Contact: 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: ;tag=314159 Call-ID: CSeq: Require: 100rel Contact: 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: ;tag=171828 To: 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: From: ;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: 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: From: ;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: 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: ;tag=a8bd703b To: ;tag=as42d9741d Call-ID: 87cbbc59e4568d6a@RXVjbGlkZS50dGkudW5pcGEuaXQ. CSeq: 1 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Contact: 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]