Internet Draft Veltri Luca October 2001 CoRiTeL Expiration: April 2002 Stefano Salsano Univ. of Rome "Tor Vergata" Donald Papalilo CoRiTeL File: SIP Extensions for QoS support in Diffserv Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This work describes an enhancement to SIP protocol for the interworking with QoS enabled IP networks. The proposed mechanism is simple and it fully preserves backward compatibility and interoperability with current SIP applications. The draft describes also the application of this mechanism to a particular QoS enabled IP network, which implements Diffserv as transport mechanisms and COPS as protocol for QoS requests and for admission control. Veltri et al. Expires April 2002 1 SIP Extensions for QoS support in Diffserv Networks Oct-01 Table of Contents Abstract........................................................1 Glossary........................................................2 1.Introduction .................................................3 2.QoS SIP: Overview ............................................4 3.Q-SIP signaling mechanism ....................................6 3.1.Q-SIP message flow .........................................6 3.2.Q-SIP protocol .............................................7 4.Q-SIP headers and fields .....................................9 4.1.CallerER header ............................................10 4.2.CalleeER header ............................................10 4.3.FirstQSIP field ............................................10 4.4.CallerER field .............................................11 4.5.Caller-media-endpoint field ................................11 5.SIP Terminals ................................................11 6.Q-SIP Servers ................................................11 7.Current Q-SIP status .........................................12 Appendix A......................................................12 Appendix B......................................................13 References......................................................16 Author Information and Acknoledgements..........................18 Glossary SIP Session Initiation Protocol RSVP Resource Reservation Protocol Intserv Integrated Services Diffserv Differentiated Services BB Bandwidth Broker ER Edge Router COPS Common Open Policy Service PDP Policy Decision Point PEP Policy Enforcement Point Q-SIP QoS enabled SIP Veltri et al. Expires April 2002 2 SIP Extensions for QoS support in Diffserv Networks Oct-01 Introduction Basically, SIP is an end-to-end session setup protocol. In order to provide satisfying quality to audio and video communication services, the reservation of resources may be needed. In the current view [1], the SIP user agent should rely on existing QoS protocols (e.g. RSVP) for the support of resource reservation. This fact has two main drawbacks: i) the user application must be aware of the QoS mechanism used in the access network and the relative QoS signaling protocol (e.g. RSVP, COPS, or other), ii) user application must implement such QoS protocol, with the increase of the client complexity. Moreover, if RSVP is used as signaling protocol, both user terminals should implement the RSVP protocol. Currently two main approaches have been proposed in the IETF for the support of QoS in an IP network: the Integrated Services (Intserv) model (strictly based on the use of RSVP), and the Differentiated Services (Diffserv) model. An IP telephony (SIP) architecture with end-to-end QoS support which can rely on the Intserv model is described in [1]. Although the Intserv model seems to be suitable for services that requires strict QoS guarantees, as for the IP telephony, it is more complex and suffers of scalability problems. For this reason the Diffserv model is now obtaining a lot of interest within the IETF and, for the same reason, it has been chosen as QoS model in this work. Figure 1 shows the reference scenario considered in this draft. The SIP terminals are connected through access networks to a core network with QoS support. The QoS provided in the core network is accessed via some QoS Access Points at the border of such network; without no loss of generality, we suppose that the QoS Access Points coincide with the network Edge Routers (ERs) (as in Figure 1). The QoS in the access networks depends on the QoS model used by the ISP for the access, but it is outside the scope of the mechanisms described in this document. /----------\ / \ .-----. .-----. / CORE \ .-----. .-----. | SIP | |Edge +---( NETWORK )---+Edge | | SIP | |phone| |Router \ / |Router |phone| '--+--' Access '--+--' \ / '--+--' Access '--+--' | Network | \----------/ | Network | --+--------------|-- --+--------------|-- Figure 1 - Reference QoS scenario In this draft we propose a very simple solution for QoS call setup that is based on the enhancement of the SIP protocol to convey end-to-end QoS related information. We will refer to such QoS aware SIP implementation as Q-SIP. The proposed QoS architecture (see Figure 2) eliminates the need of QoS supports on the user terminals since all the QoS related functions can be moved to SIP servers that will control both call setup and resource reservation, thus relieving the terminals from unneeded complexity. Veltri et al. Expires April 2002 3 SIP Extensions for QoS support in Diffserv Networks Oct-01 Basically, when a call setup is initiated, the caller SIP client can start a SIP call setup session through an outbound SIP proxy server. If needed, the server (a Q-SIP server) starts a QoS session interacting with a remote Q-SIP server and with the QoS provider (a QoS Access Point). When the QoS provider responds, the call setup can continue and finally the data session starts. The requirements at the basis of the Q-SIP proposal are: i) it should be possible to use existing SIP clients; no enhancements/modifications are needed in the SIP client applications, ii) it should be possible to have a seamless interaction with other parties which do not intend or are not able to use QoS, iii) the protocol enhancements should preserve backward compatibility with standardized SIP protocol, iv) the resulting architecture should be as simple and scalable as possible. The QoS setup procedure is dealt entirely by QoS aware agents, generally on SIP servers, and all protocol extensions needed for the QoS setup are hidden from not-QoS-aware SIP agents. Hence the solution preserves backward compatibility with current SIP applications and it de-couples as much as possible the SIP signaling from the handling of QoS. Note that, it is reasonable that in a Diffserv QoS scenario there will be servers dedicated to policy control, accounting and billing aspects. A solution based on a SIP server is really suited to this QoS scenario. QoS SIP: Overview The basic idea is that SIP clients use a default SIP proxy server in their domains for both outgoing and incoming calls. The client sends SIP messages to its proxy server and receives the messages from its server. The SIP servers are therefore involved in the message exchange between the clients and can add (and read) QoS related information in the SIP messages. This QoS information exchange is made transparent to the clients. The SIP server will extract from SIP signaling QoS parameters among them and will interact with the network QoS mechanisms. The enhanced SIP server will be called Q-SIP server (QoS enabled SIP server) in the following. The originating Q-SIP server adds QoS information in the SIP messages. This is meant as an offer to terminating SIP server, or as a hint that the originating side is capable of QoS and is willing to exploit it. If the terminating SIP server is able to handle QoS in a compatible way and it is willing to exploit it, it will answer positively with proper information in the response SIP messages. A legacy SIP server on the terminating side will not understand the QoS information in the SIP message and will silently ignore it. Obviously, the SIP session will be setup with no QoS. The reference architecture for the proposed SIP QoS scenario is depicted in Figure 2. The involved actors are the two SIP clients, the two SIP servers and a QoS enabled network. The QoS provided by the QoS enabled network is accessed by QoS Access Points located at the border of the network in the ERs. Veltri et al. Expires April 2002 4 SIP Extensions for QoS support in Diffserv Networks Oct-01 .--------. .--------. | Q-SIP | QoS enhanced SIP | Q-SIP | | server |<---------------------->| server | '--------' '--------' A A A A | | | | SIP/ |COPS COPS| \SIP / V V \ .------. / .-------. .-------. \ .------. | SIP |<-/ | QoS | | QoS | \->| SIP | |Client| | Access| | Access| |Client| '------' | Point | | Point | '------' '-------' '-------' Figure 2 _ Q-SIP architecture based on the use of Q-SIP servers. The setup of QoS session in such scenario is logically composed of two aspects: the end-to-end signaling mechanism to exchange QoS information and the QoS negotiation between the SIP agents and the QoS network. In order to design a clean and flexible solution it is important to de- couple these two aspects as much as possible. Therefore the SIP protocol mechanism to exchange QoS information should be generic and independent from the actual QoS mechanisms. Although the proposed QoS architecture will be kept very general with respect to the used QoS mechanism, for completeness we will consider a particular scenario in which the QoS aspects in the Diffserv core network are dealt via the COPS protocol [3], with specific extension as proposed in [4]. An important assumption in our scenario is that unidirectional QoS reservations for IP flows are provided by the QoS enabled network. Therefore in order to setup a bidirectional QoS communication, two different reservations have to be requested to the QoS network (RSVP QoS model works in this way). Extensions to consider QoS network that can provide bi-directional reservation are currently under study. Note that we mainly refer to a scenario where the SIP clients are un- aware of QoS aspects and the local SIP servers do all the QoS job. Actually, the proposed SIP QoS mechanism can be applied to a scenario where the SIP user applications are enhanced in order to handle the QoS aspects by themselves. The resulting scenario is depicted in Figure 3. Veltri et al. Expires April 2002 5 SIP Extensions for QoS support in Diffserv Networks Oct-01 .--------. .--------. | SIP | SIP | SIP | | server |<---------------------->| server | '--------' '--------' A A | | Q-SIP/ \Q-SIP / \ .------. / .-------. .-------. \ .------. |Q-SIP |<-/ | QoS | | QoS | \->|Q-SIP | |Client|<------->| Access| | Access|<------->|Client| '------' COPS | Point | | Point | COPS '------' '-------' '-------' Figure 3 _ Q-SIP architecture with Q-SIP agents on user terminals. Compared to Figure 2, note that SIP clients become Q-SIP clients and Q- SIP servers become SIP servers. There can even be asymmetric scenarios where one side is using a server and the other side uses a SIP application based solution (see Figure 4). .--------. .--------. | SIP | SIP | Q-SIP | | server |<---------------------->| server | '--------' '--------' A A A | | | Q-SIP/ COPS| \SIP / V \ .------. / .-------. .-------. \ .------. |Q-SIP |<-/ | QoS | | QoS | \->| SIP | |Client|<------->| Access| | Access| |Client| '------' COPS | Point | | Point | '------' '-------' '-------' Figure 4 _ Asymmetric Q-SIP architecture. Q-SIP signaling mechanism In this section we provide the detailed description of the signaling mechanisms of the proposed SIP based reservation architecture (Q-SIP). We consider a QoS scenario in which a Diffserv backbone network serves different access networks (Figure 1). The QoS requests are handled at the border of the core network by the QoS Access Points, that is, for simplicity, the Edge Routers. The ERs should implement all the mechanisms needed to perform admission control decisions (possibly with the aid of the BB) and policing function. The QoS scenario can be based on COPS as the protocol for QoS reservations. The IP phones/terminals are located on the access networks; standard SIP clients can be used and explicit SIP proxying configuration is set. When a call setup is initiated, the caller SIP client starts a SIP call setup session through the SIP proxy server. If a Q-SIP server is encountered, this will start a QoS session interacting with a remote Q-SIP server and Veltri et al. Expires April 2002 6 SIP Extensions for QoS support in Diffserv Networks Oct-01 with the QoS provider for the backbone network (i.e. the access ER). Figure 2 shows the architecture. 1.1. Q-SIP message flow With reference to Figure 2 and Figure 5, the call setup starts with a standard SIP INVITE message sent by the caller to the local Q-SIP server. The message carries the callee URI in the SIP header and the session specification within the body SDP (media, codecs, source ports, ecc). The Q-SIP server is seen by the caller as a standard SIP proxy server. The Q-SIP server, based on the caller id and on session information, decides whether a QoS session has to be started or not. If a QoS session has to be setup, it inserts the required descriptors within the INVITE message and forwards it towards the invited callee; the INVITE messages can be relayed by both standard SIP proxy servers and Q-SIP servers. When the callee responds with a 200 OK message, it is passed back to the last Q-SIP server that is the Q-SIP server that controls the callee access network. At this point the Q-SIP server on the callee side has all the information to request a specific QoS reservation to the ER on the callee access network for the callee-to-caller traffic flow. When the callee Q-SIP receive the response for the QoS reservation request, if it is positive, it stores such QoS information and send it within the 200 OK message toward the caller. The QoS information data should be stored by the Q-SIP server in order to maintain trace of the current QoS session (see also later); we call such data "QoS state".If the response for the reservation is negative, the Q-SIP server does not set a new QoS state, but it still inserts in the 200 OK response the fields needed for the caller-to-callee reservation in order to give the possibility to the caller Q-SIP server to make the reservation. When the caller Q-SIP server receives the 200 OK message with the complete QoS session indicators, it completes the QoS session setup by performing the QoS request to the ER on the caller access network for the caller-to-callee traffic flow. If the response for this flow is negative, the caller-to-callee flow will not have QoS support. The handling of these reservations refusals is different depending on QoS service model (i.e. QoS-Assured or QoS-Enabled services see [1]). Assuming a QoS-Enabled service, the Q-SIP server will simply continue with the signaling. When a call is terminated all resources that have been reserved must be released. This action is triggered by the BYE messages; when a BYE matching an installed QoS state is received, the Q-SIP server sends a release request to the QoS provider and removes the QoS state. It is important to note that the proposed architecture keeps the compatibility with standard SIP clients and standard SIP servers. As we will see in the rest of this section, all the information needed by the Q-SIP servers to perform the QoS session setup is inserted within the SIP messages in such a way that non Q-SIP aware agents can transparently manage the messages. Veltri et al. Expires April 2002 7 SIP Extensions for QoS support in Diffserv Networks Oct-01 1.2. Q-SIP protocol When the first Q-SIP server (i.e. the caller Q-SIP server) is encountered, it inserts a new field in the SIP header that is: CallerER: By means of the CallerER field the other Q-SIP servers know the IP address of the caller ER; this information is used by the callee Q-SIP server to specify the remote endpoint of the reservation in the reservation request to the QoS provider. Moreover, the caller Q-SIP server add its VIA field (as every SIP proxy), in which it includes some specific information (considered as SIP "comments") that will be not visible to any other SIP or Q-SIP server, since they are within its own VIA field. This information will be used by the same Q-SIP server while processing the 200 OK responses. The VIA field is structured as follows: VIA: SIP/2.0/udp [:] (FirstQSIP/CallerER:[/]) Fields . Note that according to the standard SIP protocol processing rules each SIP proxy that manages the INVITE message adds a new VIA field; while all the other field, as the CallerER field should be forwarded. Each Q- SIP server that manages an INVITE message containing the CallerER field, will also copy the caller ER address within its VIA field, as follows: VIA: SIP/2.0/udp [:] (CallerER:[/]) When the INVITE message reaches the callee host, the user client processes the call, and, at last, generates the 200 OK response (if the call is accepted). If the client is not aware of Q-SIP it simply discards each Q-SIP field (i.e. the CallerER) when forming the new response message. According to the SIP protocol, the fields that it has to copy from the INVITE message are the Via, To, From, CSeq and Call-ID fields. When the 200 OK reaches the callee Q-SIP server, the corresponding VIA field is read, the QoS session information are extracted (including the caller ER address) and a QoS request for the IP flow in the callee-to- caller direction can be started. (As we are considering only unidirectional reservations, two reservations in the two directions are needed)When this QoS reservation request/response phase is concluded and the resource is reserved, the QoS state is stored and the 200 OK messages is relayed toward the caller. Within this new response message, the corresponding VIA field is dropped (as required by SIP) and a new field specifying the callee ER address is inserted, that is: CalleeER: Veltri et al. Expires April 2002 8 SIP Extensions for QoS support in Diffserv Networks Oct-01 Even if the QoS reservation for the callee-to-caller flow was not successful, this field is still inserted to make possible to reserve the QoS for the caller-to-callee flow in a "QoS-Enabled" scenario. For a "QoS-Assured" one a different behavior should be performed but this is outside the scope of this document. If there are additional SIP servers handling this response in the path between the callee Q-SIP and the caller Q-SIP servers, they will only drop their own VIA field according to standard SIP rules. The Q-SIP servers recognize that they are not the callee Q-SIP server because the CalleeER field is already present in the message. When the first Q-SIP server is encountered (i.e. the caller Q-SIP server), it recognizes the field FirstQSIP within its VIA field and extracts the QoS session information (including the callee ER address). Then, it starts the QoS request for the IP flow in the caller-to-callee direction and stores the "QoS state" for this flow (if the reservation has success). It is very important to note that the use of the previously defined VIA fields lets each Q-SIP server extract all information needed for the QoS reservation directly from the SIP message that it is processing. This mechanism allows the Q-SIP not to keep per session information until a QoS call is completely installed and can be used in light Q-SIP implementations. This "QoS state" is instead needed when the call setup is completed for a correct tear-down procedure, for accounting and for resource control. In the Q-SIP, a key rule is played by the capacity of the Q-SIP servers (both the caller and the callee servers) to gather the necessary information from SIP messages in order to select the appropriate QoS reservation. Particularly the Q-SIP servers have to specify the bandwidth parameters and the flow characterization parameters (i.e. for traffic policing) in the QoS reservation request messages. The Q-SIP servers have to select the appropriate level of bandwidth, the ingress and egress ERs, and the session identification parameters (i.e. the socket identifiers). Let us now consider how the Q-SIP servers can obtain this information. As for the bandwidth that has to be requested to the QoS provider, this is selected on the base of the type of codecs specified by the end clients for the RTP streaming traffic, and found within the SIP INVITE and 200 OK messages. In Appendix B, it is reported an example of mapping table that can be used to derive the required bandwidth for well known audio codecs. It reports both the payload bit rates and the required bandwidths (taking into account the IPv4 and IPv6 headers). As for the session identification, in general different filters can be used. For example, RSVP defines for basic flow filter the destination IP address, the transport protocol identifier and (optionally) a transport address, i.e., in case of UDP/TCP, the destination port. In our architecture we use a three-fields filter composed by the source address, the destination address and the destination port. This information can be extracted from the INVITE/200 OK messages directly by the caller/callee Q-SIP servers. Note that the caller address and port information needed to setup the QoS for both directions are found within INVITE messages. The reservation is made by the caller and callee Q-SIP servers when they receive the 200 OK message. The mechanism, similarly to that used to Veltri et al. Expires April 2002 9 SIP Extensions for QoS support in Diffserv Networks Oct-01 take trace of ER information, uses a new field within the VIA field added during the processing of the INVITE message. For the caller Q-SIP server the VIA field becomes: VIA: SIP/2.0/udp [:] (FirstQSIP/CallerER:/Caller--endpoint::[/]) Where the parameter indicates which media uses the specified caller address; the address is used as source address for the caller-to- callee flow. For the other Q-SIP server (hence also for the callee Q-SIP server) the VIA field becomes: VIA: SIP/2.0/udp [:] (CallerER:/Caller--endpoint::[/]) Where the parameter indicates which media uses the specified caller address and port, as destination for the callee-to-caller flow. The remaining information is extracted directly from the 200 OK message (the callee address from the callee Q-SIP server and the callee address and port from the caller Q-SIP server). The Q-SIP call setup flow is shown in Figure 5. The tear down procedure is triggered at the caller/callee Q-SIP servers by the receiving of the BYE and 200 OK messages. When a Q-SIP server receives the BYE request associated to a session with QoS, it requests the releasing of the bandwidth for that session to the QoS provider. If required, the resource details could be retrieved from the stored QoS state. In appendix A there is a sample of the QoS state that can be associated with each QoS call. When a BYE request matches one of the stored call-leg, the Q-SIP server releases the resources by interacting with the QoS provider and frees the QoS state. If a BYE message gets lost due to a terminal failure, the session tear-down should be initiated (automatically) by the other SIP terminal as a result of a session time-out. In order to ensure that the SIP signaling will cross the Q-SIP servers, the Record-Route and Route headers are used as defined by SIP [2]. The Q-SIP server inserts the Record-Route header for the sessions with QoS requests, making sure that further signaling will cross the Q-SIP server itself. Q-SIP headers and fields 1.3. CallerER header header: CallerER: remarks: Veltri et al. Expires April 2002 10 SIP Extensions for QoS support in Diffserv Networks Oct-01 It is inserted in the INVITE messages by the first encountered Q-SIP server (i.e. the caller Q-SIP server) and indicates to all other Q-SIP servers the IP address of the caller ER. This information is used by the callee Q-SIP server to specify the remote endpoint of the reservation in the reservation request to the QoS provider. 1.4. CalleeER header header: CalleeER: remarks: It is inserted by last Q-SIP server, that is the first from the callee (i.e. the Callee Q-SIP server) after the reception of the 200 OK message and after the reservation procedure. It indicates the IP address of the callee ER to the caller Q-SIP server; it also advises the other Q-SIP servers to skip Q-SIP protocol information. SIP SIP Edge Edge SIP SIP Terminal Server Router Router Server Terminal | | | | | | | INVITE | INVITE | | | INVITE | |--------->|------------------------------->|--------->| | | | | | | |180ringing| | |180ringing|180ringing| |<---------|<-------------------------------|<---------| | | | | | | | | | | | 200 OK | | | | | COPS |<---------| | | | |<---------| | | | | | COPS | | | | | |--------->| | | | | | 200 OK | | | |<-------------------------------| | | | COPS | | | | | |--------->| | | | | | COPS | | | | | 200 OK |<---------| | | | |<---------| | | | | | | | | | | | ACK | ACK | | | ACK | |--------->|------------------------------->|--------->| | | | | | | | Traffic | | | | Traffic | |<====================================================>| | | | | | | Figure 5 _ Q-SIP call signaling flow 1.5. FirstQSIP field field: Veltri et al. Expires April 2002 11 SIP Extensions for QoS support in Diffserv Networks Oct-01 (FirstQSIP[/]) remarks: It is inserted as a comment by the first Q-SIP server within its own VIA header. 1.6. CallerER field field: ([/]CallerER:[/]) remarks: It is inserted as a comment by every Q-SIP servers within their own VIA header; it reports the same address specified by the Caller ER header. 1.7. Caller-media-endpoint field field: ([/]Caller--endpoint:[:][/]) remarks: If inserted by the first Q-SIP server it reports only, for each media, the caller IP address (i.e. caller-to-callee source addresses), while if inserted by the other Q-SIP servers, it reports for each media the caller IP address and port (i.e. callee-to-caller destination addresses and ports). A set of example Q-SIP messages is reported in Appendix C. SIP Terminals Although it has been supposed that the SIP user clients are not aware of the Q-SIP reservation mechanism, Q-SIP aware clients can be also considered (Figure 3). Q-SIP aware clients should simply include Q-SIP as described in the previous sections. In that case, the clients could directly request QoS reservation to the QoS providers and the Q-SIP signaling would transparently bypass any SIP or Q-SIP proxy server. Moreover the architecture is fully compatible also for calls starting from Q-SIP aware clients and directed to standard SIP clients with Q-SIP proxy servers, and vice-versa (Figure 4). Q-SIP Servers A basic design choice in the design of a SIP proxy server is whether to make it stateful or stateless. Being stateful means that it keeps a record of active SIP session and the processing of SIP messages can depend on the session status. Being stateless means that each message is processed by itself with no relations with previous messages of the same session. A stateful server of course is more powerful as it can better handle additional aspects (like for example policy and accounting), but Veltri et al. Expires April 2002 12 SIP Extensions for QoS support in Diffserv Networks Oct-01 the SIP protocol has been designed so that stateless server can work as well. Looking at our approach, we note that the Q-SIP server handles the QoS for a SIP session, by making a reservation in the QoS enabled network. The Q-SIP server has to care about this reservation, for example the resources must be properly released when the session is closed. For this reason we believe that the Q-SIP server must be stateful once the session has been established. Nevertheless, we have designed our Q-SIP extensions preserving the SIP design goals: there is no need to store state information during the session establishment and all the needed information is carried by the SIP messages itself. Current Q-SIP status This is the first draft of the Q-SIP. New features can be introduced in future versions of the drafts. However, the present protocol definition is in a stable status and it is ready for implementation. A prototype implementation has been realized and will be soon available [5]. The messages reported in Appendix C are extracted from the current implementation in a simple successful SIP call that involves two Q-SIP servers. Appendix A A possible implementation of the QoState : ::= The Call-Identification has the following format: ::= The scope of the reservation has the following format : ::= The Session identification filter has the following format: ::= According to the assumptions made before, that the QoState in our scenario refers to a unidirectional flow inside the core network. Veltri et al. Expires April 2002 13 SIP Extensions for QoS support in Diffserv Networks Oct-01 Appendix B |---------|---------|---------|-----------------------| | | Payload | Payload | | | Code | Type | Bit-Rate| Bandwidth (IPv4/IPv6) | | | | (kbit/s)| (kbit/s) | |---------|---------|---------|-----------------------| | PCMU | 0 | 64 | 81.6 / 88 | | 1016 | 1 | 16 | 33.6 / 40 | | G.721 | 2 | 32 | 49.6 / 56 | | GSM | 3 | 13 | 30.6 / 37 | | G.723 | 4 | 6.3 | 23.9 / 30.3 | | DV14 | 5 | 32 | 49.6 / 56 | | DV14(2) | 6 | 64 | 81.6 / 88 | | LPC | 7 | 2.4 | 20 / 26.6 | | PCMA | 8 | 64 | 81.6 / 88 | | G.722 | 9 | 64 | 81.6 / 88 | | MPA | 14 | 32 | 49.6 / 56 | | G.728 | 15 | 16 | 33.6 / 40 | | G.729 | 18 | 8 | 25.6 / 32 | | | | | | |---------|---------|---------|-----------------------| Appendix C Examples of Q-SIP messages in the successful reservation scenario depicted in the picture hereafter. The messages are numbered from M1 to M18. Only the messages sent by the proxy servers are reported in detail. The reported messages are recorded in our testbed, using our implementation of the Q-SIP server. Veltri et al. Expires April 2002 14 SIP Extensions for QoS support in Diffserv Networks Oct-01 gauss.coritel.it maxwell.coritel.it eulero.coritel.it galileo.coritel.it User A Proxy 1 Proxy 2 User B | INVITE M1 | | | |--------------->| INVITE M2 | | | |--------------->| INVITE M3 | | | |--------------->| | 180ringing M6 | 180ringing M5 | 180ringing M4 | |<---------------|<---------------|<---------------| | | | 200 OK M7 | | | 200 OK M8 |<---------------| | 200 OK M9 |<---------------| | |<---------------| | | | ACK M10 | ACK M11 | ACK M12 | |--------------->|--------------->|--------------->| | RTP Media | |<================================================>| | | | BYE M13 | | | BYE M14 |<---------------| | BYE M15 |<---------------| | |<---------------| | | | 200 OK M16 | 200 OK M17 | 200 OK M18 | |--------------->|--------------->|--------------->| Message M2 (INVITE from Proxy 1 to Proxy 2): INVITE sip:UserB@maxwell.coritel.it SIP/2.0 Via: SIP/2.0/udp gauss.coritel.it:5060 (FirstSSIP/Caller_media_endpoint: 151.100.37.131,49172) Via: SIP/2.0/UDP eulero.coritel.it:5060 From: UserA To: UserB Server: Coritel SIP Server 1.0 Record-Route: CallerER: 192.168.50.2 Call-ID: 12345600@eulero.coritel.it CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 148 v=0 o=UserA 2890844526 2890844526 IN IP4 eulero.coritel.it s=Session SDP c=IN IP4 151.100.37.131 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Veltri et al. Expires April 2002 15 SIP Extensions for QoS support in Diffserv Networks Oct-01 Message M3 (INVITE from Proxy 2 to User B): INVITE sip:UserB@galileo.coritel.it:5060 SIP/2.0 Via: SIP/2.0/udp maxwell.coritel.it:5060 (Caller_media_endpoint: 151.100.37.131,49172/CallerER: 192.168.50.2) Via: SIP/2.0/udp gauss.coritel.it:5060 (FirstSSIP/Caller_media_endpoint: 151.100.37.131,49172) Via: SIP/2.0/UDP eulero.coritel.it:5060 From: UserA To: UserB Server: Coritel SIP Server 1.0 Record-Route: , Server: Coritel SIP Server 1.0 CallerER: 192.168.50.2 Call-ID: 12345600@eulero.coritel.it CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 148 v=0 o=UserA 2890844526 2890844526 IN IP4 eulero.coritel.it s=Session SDP c=IN IP4 151.100.37.131 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Veltri et al. Expires April 2002 16 SIP Extensions for QoS support in Diffserv Networks Oct-01 Message M8 (200 OK from Proxy 2 to Proxy1): SIP/2.0 200 OK Via: SIP/2.0/UDP gauss.coritel.it:5060 (FirstSSIP/Caller_media_endpoint: 151.100.37.131,49172) Via: SIP/2.0/UDP eulero.coritel.it:5060 Record-Route: , From: UserA To: UserB;tag=110673 CalleeER: 192.168.150.31 Call-ID: 12345600@eulero.coritel.it CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 148 v=0 o=UserB 2890844527 2890844527 IN IP4 galileo.coritel.it s=Session SDP c=IN IP4 151.100.37.143 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Veltri et al. Expires April 2002 17 SIP Extensions for QoS support in Diffserv Networks Oct-01 Message M9 (200 OK from Proxy 1 to User A): SIP/2.0 200 OK Via: SIP/2.0/UDP eulero.coritel.it:5060 Record-Route: , From: UserA To: UserB;tag=110673 CalleeER: 192.168.150.31 Call-ID: 12345600@eulero.coritel.it CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 148 v=0 o=UserB 2890844527 2890844527 IN IP4 galileo.coritel.it s=Session SDP c=IN IP4 151.100.37.143 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Message M14 (BYE from Proxy 2 to Proxy 1): BYE sip:UserA@gauss.coritel.it SIP/2.0 Via: SIP/2.0/udp maxwell.coritel.it:5060 Via: SIP/2.0/UDP galileo.coritel.it:5060 Route: From: UserB;tag=110673 To: UserA Server: Coritel SIP Server 1.0 Call-ID: 12345600@eulero.coritel.it CSeq: 1 BYE Content-Length: 0 Message M15 (BYE from Proxy 1 to user A) BYE sip:UserA@eulero.coritel.it:5060 SIP/2.0 Via: SIP/2.0/udp gauss.coritel.it:5060 Via: SIP/2.0/udp maxwell.coritel.it:5060 Via: SIP/2.0/UDP galileo.coritel.it:5060> From: UserB;tag=110673 To: UserA Server: Coritel SIP Server 1.0 Server: Coritel SIP Server 1.0 Call-ID: 12345600@eulero.coritel.it CSeq: 1 BYE Content-Length: 0 Veltri et al. Expires April 2002 18 SIP Extensions for QoS support in Diffserv Networks Oct-01 References [1] W. Marshall et al. "Integration of Resource Management and SIP", IETF Internet Draft , August 2001, Work in Progress. [2] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, " SIP: Session Initiation Protocol", IETF Internet Drafts < draft-ietf-sip- rfc2543bis-02.txt>, November 2000. [3] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, The COPS (Common Open Policy Service) Protocol, IETF RFC 2748, January 2000. [4] S. Salsano " COPS Usage for Diffserv Resource Allocation (COPS- DRA), draft-salsano-cops-dra-00.txt, October 2001, work in progress [5] CoRiTeL The Q-SIP project http://www.coritel.it/projects/qsip Veltri et al. Expires April 2002 19 SIP Extensions for QoS support in Diffserv Networks Oct-01 Author Information and Acknoledgements Special thanks to Jocelyn Fiorina for his comments and suggestions and for the work on the prototype implementation. Luca Veltri CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni Via Anagnina, 203 00040 Roma - ITALY email: veltri@coritel.it Stefano Salsano DIE - University of Rome "Tor Vergata" Via di Tor Vergata, 110 00133 Roma - ITALY email: salsano@coritel.it Donald Papalilo CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni Via Anagnina, 203 00040 Roma - ITALY email: papalilo@coritel.it Veltri et al. Expires April 2002 20