idnits 2.17.1 draft-veltri-sip-qsip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 39 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 855: '...ery Q-SIP server MUST be able to act a...' RFC 2119 keyword, line 886: '...ateless Q-SIP rules MUST be satisfied....' RFC 2119 keyword, line 887: '...de Q-SIP servers MUST insert the "qos-...' RFC 2119 keyword, line 980: '...s for a possible QoS session SHOULD be...' RFC 2119 keyword, line 983: '...server, proxy authentication SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1527 has weird spacing: '...itel.it maxwe...' == Line 1689 has weird spacing: '...itel.it maxwe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2976 (ref. '7') (Obsoleted by RFC 6086) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Luca Veltri 3 October 2002 CoRiTeL 4 Expiration: April 2003 Stefano Salsano 5 Univ. of Rome "Tor Vergata" 6 Donald Papalilo 7 CoRiTeL 8 File: 10 SIP Extensions for QoS support 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this memo is unlimited. 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This work describes an enhancement to SIP protocol for the interworking 41 with QoS enabled IP networks. The proposed mechanism is simple and it 42 fully preserves backward compatibility and interoperability with current 43 SIP applications. The draft describes also, as an example, the 44 application of this mechanism to a particular QoS enabled IP network, 45 which implements Diffserv as transport mechanisms and COPS as protocol 46 for QoS requests and for admission control. 48 Veltri et al. Expires April 2003 1 49 Table of Contents 51 Abstract........................................................1 52 Glossary........................................................2 53 1. Introduction.................................................3 54 2. QoS SIP: Overview............................................5 55 2.1 QoS reservation modes.......................................7 56 2.2 QoS models..................................................8 57 3. Q-SIP signaling mechanism....................................8 58 3.1 Q-SIP message flow..........................................9 59 3.1.1 Q-SIP message flow - unidirectional QoS reservation.......9 60 3.1.2 Q-SIP message flow - bidirectional QoS reservation........11 61 3.2 Q-SIP protocol..............................................12 62 3.2.1 Stateful variant of Q-SIP protocol........................13 63 3.2.2 Stateless variant of the Q-SIP protocol...................15 64 4. Q-SIP syntax and rules.......................................17 65 4.1 Syntax......................................................17 66 4.2 Rules.......................................................18 67 5. Use of INFO method for robust tear-down procedure............19 68 6. SIP Terminals................................................19 69 7. Q-SIP Servers................................................20 70 8. Security Considerations......................................20 71 9. Change log and prototype implementation......................20 72 Appendix A: QoS-Enabled vs. QoS-Assured.........................21 73 A.1 Q-SIP using unidirectional QoS Network reservation.........21 74 A.1.1 Bidirectional e2e reservation sender initiated...........21 75 A.1.2 Unidirectional e2e reservation sender initiated..........23 76 A.1.3 Bidirectional e2e reservation receiver initiated.........24 77 A.1.4 Unidirectional e2e reservation receiver initiated........26 78 A.2 Q-SIP using bidirectional QoS Network reservation..........27 79 A.2.1 Bidirectional e2e reservation sender initiated...........27 80 A.2.2 Bidirectional e2e reservation receiver initiated.........29 81 Appendix B - Description of the QoS State.......................30 82 Appendix C - Payload type vs. bandwidth.........................31 83 Appendix D - Examples of Q-SIP messages.........................32 84 Appendix E......................................................36 85 References......................................................41 86 Author Information and Acknoledgements..........................42 88 Veltri et al. Expires April 2003 2 89 Glossary 91 SIP Session Initiation Protocol 92 RSVP Resource Reservation Protocol 93 Intserv Integrated Services 94 Diffserv Differentiated Services 95 BB Bandwidth Broker 96 ER Edge Router 97 COPS Common Open Policy Service 98 PDP Policy Decision Point 99 PEP Policy Enforcement Point 100 Q-SIP QoS enabled SIP 101 NSIS Next Steps in Signaling 102 UA User Agent 104 1. Introduction 106 Basically, SIP is an end-to-end session setup protocol. In order to 107 provide an adequate quality of services for audio and video 108 communications, a form of resource reservation may be needed. In the 109 current view [1][3], the SIP user agents should rely on existing QoS 110 protocols (e.g. RSVP) for the support of such resource reservation. 111 This fact has two main drawbacks: i) the user applications must be aware 112 of the QoS mechanism used in the access network and the relative QoS 113 signaling protocol (e.g. RSVP, COPS, or other), ii) user applications 114 must implement such QoS protocol, with the increase of the complexity. 115 Moreover, if RSVP is used as signaling protocol, both user terminals 116 should implement the RSVP protocol. 117 Currently two main approaches have been proposed in the IETF for the 118 support of QoS in an IP network: the Integrated Services (Intserv) model 119 (strictly based on the use of RSVP), and the Differentiated Services 120 (Diffserv) model. 121 An IP telephony (SIP based) architecture with end-to-end QoS support 122 which can rely on the Intserv model is described in [1]. Although the 123 Intserv model seems to be suitable for services that requires strict QoS 124 guarantees, as for the IP telephony, it is more complex and suffers of 125 scalability problems. For this reason the Diffserv model has been chosen 126 as QoS model in this work. 127 The NSIS IETF WG [2] is currently elaborating the signaling aspects that 128 could support IP QoS. The reference model it is still under a discussion 129 phase, and it is not completely defined. However, the architecture here 130 presented seems to be quite aligned with the drafts under discussion 131 within NSIS. 133 Figure 1 shows the reference scenario considered in this draft. 135 Veltri et al. Expires April 2003 3 136 The SIP terminals are connected through access networks to a core 137 network with QoS support. The QoS provided in the core network is 138 accessed via some QoS Access Points at the border of such network; 139 without no loss of generality, we suppose that the QoS Access Points 140 coincide with the network Edge Routers (ERs) (as in Figure 1). The QoS 141 in the access networks depends on the QoS model used by the ISP for the 142 access, but it is outside the scope of the mechanisms described in this 143 document. 144 /------\ 145 __/ \__ 146 .-----. .-----. / CORE \ .-----. .-----. 147 | SIP | |Edge +---( NETWORK )---+Edge | | SIP | 148 |phone| |Router \__ __/ |Router |phone| 149 '--+--' Access '--+--' \ / '--+--' Access '--+--' 150 | Network | \------/ | Network | 151 --+--------------|-- --+--------------|-- 153 Figure 1 - Reference QoS scenario 155 In this draft we propose a very simple solution for QoS call setup that 156 is based on the enhancement of the SIP protocol to convey end-to-end QoS 157 related information. We will refer to such QoS aware SIP implementation 158 as Q-SIP. 159 The proposed QoS architecture (see Figure 2) eliminates the need of QoS 160 supports on the user terminals since all the QoS related functions can 161 be moved to (local) SIP servers that will control both call setup and 162 resource reservation, thus relieving the terminals from unneeded 163 complexity. 164 Basically, when a call setup is initiated, the caller SIP UA can start a 165 SIP call setup session through an outbound SIP proxy server. If needed, 166 the server (a Q-SIP server) starts a QoS session interacting with a 167 remote Q-SIP server and with the QoS provider (a QoS Access Point). When 168 the QoS provider responds, the call setup can continue and finally the 169 data session starts. 170 The requirements at the basis of the Q-SIP proposal are: 171 i) it should be possible to use existing SIP UAs; no 172 enhancements/modifications are needed in the SIP UA applications, 173 ii) it should be possible to have a seamless interaction with other 174 parties which do not intend or are not able to use QoS, 175 iii) the protocol enhancements should preserve backward compatibility 176 with standardized SIP protocol, 177 iv) the resulting architecture should be as simple and scalable as 178 possible, 179 v) the architecture should be extendible to new models of QoS support 180 for IP networks. 182 The QoS setup procedure is dealt entirely by QoS aware agents, generally 183 on SIP servers, and all protocol extensions needed for the QoS setup are 184 hidden from not-QoS-aware SIP agents. Hence the solution preserves 185 backward compatibility with current SIP applications and it de-couples 186 as much as possible the SIP signaling from the handling of QoS. 187 Note that, it is reasonable that in a Diffserv QoS scenario there will 188 be servers dedicated to policy control, accounting and billing aspects. 190 Veltri et al. Expires April 2003 4 191 A solution based on a SIP server is really suited to this QoS scenario. 192 In the light of the current discussion in NSIS, the proposed Q-SIP 193 server would act as a QoS Initiator interacting with a QoS Controller. 194 The end-to-end SIP signaling can interact with the reservation of 195 resource using "out of band" NSIS signaling. 197 2. QoS SIP: Overview 199 The basic idea is that SIP UAs use a default SIP proxy server in their 200 domains for both outgoing and incoming calls. The UA sends SIP messages 201 to its proxy server and receives the messages from its server. The SIP 202 servers are therefore involved in the message exchange between the UAs 203 and can add (and read) QoS related information in the SIP messages. This 204 QoS information exchange is made transparent for the UAs. The SIP server 205 will extract from SIP signaling QoS parameters among them and will 206 interact with the network QoS mechanisms. The enhanced SIP server will 207 be called Q-SIP server (QoS enabled SIP server). 208 The originating Q-SIP server adds QoS information in the SIP messages. 209 This is meant as an offer to terminating SIP server, or as a hint that 210 the originating side is capable of QoS and is willing to exploit it. If 211 the terminating SIP server is able to handle QoS in a compatible way and 212 it is willing to exploit it, it will answer positively with proper 213 information in the response SIP messages. A legacy SIP server on the 214 terminating side will not understand the QoS information in the SIP 215 message and will silently ignore it. Obviously, the SIP session will be 216 setup with no QoS. 218 The reference architecture for the proposed SIP QoS scenario is depicted 219 in Figure 2 and Figure 3. The involved actors are the two SIP UAs, the 220 two SIP servers and a QoS enabled network. The QoS provided by the QoS 221 enabled network is accessed by QoS Access Point(s) located at the border 222 of the network in the ERs. Depending on the mechanism implemented inside 223 the core network in order to handle the reservation, there can be two 224 logical types of QoS Access Points distinguished by the type of 225 reservation offered: unidirectional and bidirectional from an ingress to 226 an egress point (ER). 228 .--------. .--------. 229 | Q-SIP | QoS enhanced SIP | Q-SIP | 230 | server |<---------------------->| server | 231 '--------' '--------' 232 A A A A 233 | | | | 234 SIP/ | <- COPS/NSIS/other -> | \SIP 235 / V V \ 236 .------. / .-------. .-------. \ .------. 237 | SIP |<-/ | QoS | | QoS | \->| SIP | 238 | UA | | Access| | Access| | UA | 239 '------' | Point | | Point | '------' 240 '-------' '-------' 241 Figure 2 - Q-SIP architecture based on the use of Q-SIP servers on QoS 242 IP networks that offer unidirectional flow reservation. 244 Veltri et al. Expires April 2003 5 245 .--------. .--------. 246 | Q-SIP | QoS enhanced SIP | Q-SIP | 247 | server |<---------------------->| server | 248 '--------' '--------' 249 A A A 250 | | | 251 SIP/ |COPS/NSIS/other \SIP 252 / V \ 253 .--------. / .-------. \ .--------. 254 | SIP |<-/ | QoS | \->| SIP | 255 | UA | | Access| | UA | 256 |(caller)| | Point | |(callee)| 257 '--------' '-------' '--------' 258 Figure 3 - Q-SIP architecture based on the use of Q-SIP servers on QoS 259 IP networks that offer bidirectional flow reservation. 261 The setup of QoS sessions in such scenario is logically composed of two 262 aspects: the end-to-end signaling mechanism to exchange QoS information 263 and the QoS negotiation between the SIP agents and the QoS network. 264 In order to design a clean and flexible solution it is important to de- 265 couple these two aspects as much as possible. Therefore the SIP protocol 266 mechanism to exchange QoS information should be generic and independent 267 from the actual QoS mechanisms. 268 Although the proposed QoS architecture will be kept very general with 269 respect to the used QoS mechanism, for completeness we will consider a 270 particular scenario in which the QoS aspects in the Diffserv core 271 network are dealt via the COPS protocol [4], with specific extension as 272 proposed in [5]. 273 In our scenarios, the QoS enabled network can provide unidirectional or 274 bidirectional QoS reservations. In the first case, two different 275 reservations have to be requested to the QoS network (also RSVP QoS 276 model works in this way). When considering a QoS IP network that can 277 provide bidirectional reservations, the difference is that we have a 278 single QoS Access Point and a single reservation request made by the Q- 279 SIP. 280 Note that we mainly refer to a scenario where the SIP UAs are un-aware 281 of QoS aspects and the local SIP servers do all the QoS job. Actually, 282 the proposed SIP QoS mechanism can be applied also to a scenario where 283 the SIP user applications are enhanced in order to handle the QoS 284 aspects by themselves. The resulting scenario is depicted in Figure 4. 286 Veltri et al. Expires April 2003 6 287 .--------. .--------. 288 | SIP | Q-SIP | SIP | 289 | server |<---------------------->| server | 290 '--------' '--------' 291 A A 292 | | 293 Q-SIP/ \Q-SIP 294 / \ 295 .------. / .-------. .-------. \ .------. 296 |Q-SIP |<-/ | QoS | | QoS | \->|Q-SIP | 297 | UA |<------->| Access| | Access|<------->| UA | 298 '------' COPS/ | Point | | Point | COPS/ '------' 299 NSIS/ '-------' '-------' NSIS/ 300 OTHER OTHER 301 Figure 4 _ Q-SIP architecture with Q-SIP agents on user terminals. 303 Compared to Figure 2, note that SIP UAs become Q-SIP UAs and Q-SIP 304 servers become SIP servers. There can even be asymmetric scenarios where 305 one side is using a server and the other side uses a SIP application 306 based solution (see Figure 5). 308 .--------. .--------. 309 | SIP | Q-SIP | Q-SIP | 310 | server |<---------------------->| server | 311 '--------' '--------' 312 A A A 313 | | | 314 Q-SIP/ COPS/NSIS/OTHER| \Q-SIP 315 / V \ 316 .------. / .-------. .-------. \ .------. 317 |Q-SIP |<-/ | QoS | | QoS | \->| SIP | 318 | UA |<------->| Access| | Access| | UA | 319 '------' COPS/ | Point | | Point | '------' 320 NSIS/ '-------' '-------' 321 OTHER 322 Figure 5 _ Asymmetric Q-SIP architecture. 324 2.1 QoS reservation modes 326 As far as the reservation procedure is concerned, two different models 327 are possible: i) unidirectional reservations and ii) bidirectional 328 reservations. In the unidirectional reservation mode, the caller-side Q- 329 SIP server makes reservation for the caller-to-callee traffic flow, 330 while the callee-side Q-SIP server reserves resources for the callee-to- 331 caller flow; two reservations are hence needed for bidirectional flows. 332 Instead, in the bidirectional reservation mode, it is the caller-side Q- 333 SIP server that performs resource reservation for both directions. The 334 choice between the two models can be done on the basis of a pre- 335 configured mode or through the exchange of specific parameters ("qos- 336 mode" parameters) between the Q-SIP servers during the call setup phase. 338 Veltri et al. Expires April 2003 7 339 2.2 QoS models 341 When the requested resource needed for a QoS call is not available, two 342 options are possible: i) the call is setup without QoS, ii) the call is 343 rejected. These two options are at the basis of the following two QoS 344 models: 345 i) "QoS-Assured", that is the session should not be established if 346 resources are not available; in this case the QoS should be setup before 347 alerting the user avoiding that a user may respond to a call when 348 resources are not available. 349 ii) "QoS-Enabled", that is the session is established regardless of the 350 availability of QoS resources; eventually the user may be signaled about 351 the presence of QoS. 352 In [1] the "QoS-Assured" model is considered. A possible interaction 353 between SIP and resource management and a precondition framework is 354 described. 355 On the contrary, the present proposal starts from the analysis of a 356 "QoS-Enabled" model, where the reservation of resources is not a 357 mandatory precondition and can be executed in parallel with normal 358 session setup. The extension of our proposal to a "QoS-Assured" model 359 (conforming to [1]) is reported in Appendix A. 361 3. Q-SIP signaling mechanism 363 This section provides the detailed description of the signaling 364 mechanisms of the proposed SIP based reservation architecture (Q-SIP). 365 We consider a QoS scenario in which a Diffserv backbone network serves 366 different access networks (Figure 1). The QoS requests are handled at 367 the border of the core network by the QoS Access Point(s). In the 368 following we assume that the Edge Router(s) act as QoS Access Point and 369 implement all the mechanisms needed to perform admission control 370 decisions (possibly with the aid of a Bandwidth Broker (BB)) and 371 policing function. As an example, the QoS scenario will be based on COPS 372 as the protocol for QoS reservations. 373 The IP phones/terminals are located on the access networks; standard SIP 374 UAs can be used and explicit SIP proxying configuration is set. When a 375 call setup is initiated, the caller SIP UA starts a SIP call setup 376 session through the SIP proxy server. If a Q-SIP server is encountered, 377 this will start a QoS session interacting with a remote Q-SIP server and 378 with the QoS provider for the backbone network (i.e. the access ER). 379 According to the direction of the call, the two Q-SIP servers are named 380 caller-side Q-SIP server and callee-side Q-SIP server. The reference 381 architecture is shown in Figure 2. 382 The basic goal of the Q-SIP signaling mechanism is to let the two parts 383 (i.e. the Q-SIP servers) that are willing to setup a QoS session to 384 interact each other and to exchange the needed information (e.g. IP 385 addresses of ingress and egress QoS elements). A new SIP header (QoS- 386 Info) will be defined for this purpose. We defined two variants of the 387 procedure depending on the state information that is kept in the Q-SIP 388 server during the session setup. One of the design goal of the SIP 389 protocol is that a SIP proxy server should operate in a stateless way 390 whenever possible, i.e. it should not be required for it to record any 392 Veltri et al. Expires April 2003 8 393 session state. If we want to keep this principle for our Q-SIP server 394 operation, some information will be recorded in the SIP request messages 395 in a special way so that the servers will find this information in the 396 SIP response messages. This will be the "stateless" variant of the Q-SIP 397 protocol. Anyway, considering that the Q-SIP server is probably 398 interested to store a QoS state for the call session after its 399 establishment, it can be reasonable to store some state also during the 400 session setup. Relying on this state, the information that will be 401 transported in SIP messages will be simpler ("stateful" variant of the 402 Q-SIP protocol). 404 3.1 Q-SIP message flow 406 In this section the description of the Q-SIP procedure is given, for the 407 two types of reservations offered by the QoS enabled network: 408 unidirectional or bidirectional modes. Note that the Q-SIP server must 409 be aware (e.g. by configuration) of the type of reservation offered by 410 the QoS enabled network. 412 3.1.1 Q-SIP message flow - unidirectional QoS reservation 414 With reference to Figure 6, the call setup starts with a standard SIP 415 INVITE message sent by the caller to the local Q-SIP server (caller-side 416 Q-SIP server). The message carries the callee URI in the SIP header and 417 the session specification within the body SDP (media, codecs, source 418 ports, etc). The Q-SIP server is seen by the caller as a standard SIP 419 proxy server. The Q-SIP server, based on the caller identity and on 420 session information, decides whether a QoS session has to be started or 421 not. Note that the service admission decision can be handled locally 422 relying in a user profile or demanded to another external admission 423 control entity, but this is outside the scope of this work. 424 If a QoS session has to be setup, the Q-SIP server extracts the required 425 information from the message, inserts the additional Q-SIP header and 426 the Record-Route header information (to assure that all the messages for 427 this session will pass through itself) within the INVITE message. 428 If the stateful variant is used, some information is stored by the Q-SIP 429 server in order to maintain trace of the current QoS session. We will 430 refer to such information as "provisional QoS state". 431 If the stateless variant is used, the required information is stored as 432 additional fields in the Record Route header. 433 Then the Q-SIP forwards the INVITE message towards the invited callee; 434 the INVITE messages can be relayed by both standard SIP proxy servers 435 and Q-SIP servers. When the Q-SIP server on the callee side (callee-side 436 Q-SIP server) receives an INVITE message that contains the SIP QoS 437 extensions, it understands that a session with QoS has to be setup. 438 Therefore it extracts the needed information from the message, removes 439 the Q-SIP extension and inserts Record-Route header. In case of the 440 stateful variant, it initializes the "provisional QoS state", like the 441 caller-side Q-SIP. In case of the stateless variant, it adds additional 442 information in the Record-Route header. 443 When the callee responds with a 200 OK message, it is passed back to the 444 last Q-SIP server that is the Q-SIP server that controls the access 446 Veltri et al. Expires April 2003 9 447 network of the callee. At this point the Q-SIP server on the callee side 448 has all the information to request a specific QoS reservation to the ER 449 on the callee access network for the callee-to-caller traffic flow. When 450 the callee-side Q-SIP receive a positive response for the QoS 451 reservation request, it stores such QoS information completing the QoS 452 state and sends the extension information for the callee side within the 453 200 OK message toward the caller. The QoS information data is stored by 454 the Q-SIP server. In case of the stateful variant, this QoS information 455 complete the QoS state previously stored. If the response for the 456 reservation is negative, the Q-SIP server update the QoS state and it 457 still inserts in the 200 OK response the extension header field needed 458 for the caller-to-callee reservation in order to give the possibility to 459 the caller-side Q-SIP server to make the reservation. The update of the 460 QoS state reports the failure of the reservation so retransmissions of 461 the 200 OK does not trigger QoS reservation request and only the 462 extension header field is inserted to handle correctly the message 463 retransmission. Actually, the handling of these reservations refusals is 464 different depending on QoS service model (i.e. QoS-Assured or QoS- 465 Enabled). Assuming a QoS-Enabled service, the Q-SIP server will simply 466 continue with the signaling. 467 When the caller-side Q-SIP server receives the 200 OK message with the 468 complete QoS session indicators, it completes the QoS session setup by 469 performing the QoS request to the ER on the caller access network for 470 the caller-to-callee traffic flow. If the response for this flow is 471 negative, the caller-to-callee flow will not have QoS support and the 472 QoS state previously installed is treated as in the callee-side Q-SIP 473 server in order to handle correctly retransmissions. If the response is 474 positive, the QoS state is completed. 475 When a call is terminated all resources that have been reserved must be 476 released. This action is triggered by the BYE messages; when a BYE 477 matching an installed QoS state is received, the Q-SIP server sends a 478 release request to the QoS provider and removes the QoS state. Another 479 way to assure the release of the resources, based on the use of time- 480 outs and the INFO method, is described in section 5. 482 It is important to note that the proposed architecture keeps the 483 compatibility with standard SIP UAs and standard SIP servers. As we will 484 see in the rest of this section, all the information needed by the Q-SIP 485 servers to perform the QoS session setup is inserted within the SIP 486 messages in such a way that non Q-SIP aware agents can transparently 487 manage the messages. 489 Veltri et al. Expires April 2003 10 490 SIP SIP Edge Edge SIP SIP 491 Terminal Server Router Router Server Terminal 492 | | | | | | 493 | INVITE | INVITE | | | INVITE | 494 |--------->|------------------------------->|--------->| 495 | | | | | | 496 |180ringing| | |180ringing|180ringing| 497 |<---------|<-------------------------------|<---------| 498 | | | | | | 499 | | | | | 200 OK | 500 | | | | COPS |<---------| 501 | | | |<---------| | 502 | | | | COPS | | 503 | | | |--------->| | 504 | | | | 200 OK | | 505 | |<-------------------------------| | 506 | | COPS | | | | 507 | |--------->| | | | 508 | | COPS | | | | 509 | 200 OK |<---------| | | | 510 |<---------| | | | | 511 | | | | | | 512 | ACK | ACK | | | ACK | 513 |--------->|------------------------------->|--------->| 514 | | | | | | 515 | Traffic | | | | Traffic | 516 |<====================================================>| 517 | | | | | | 519 Figure 6 _ Q-SIP call signaling flow - unidirectional QoS mode 521 3.1.2 Q-SIP message flow - bidirectional QoS reservation 523 The fundamental difference from the QoS unidirectional reservation mode 524 is that now there is only one interaction with the QoS provider, as 525 depicted in Figure 3. In this case when the caller-side Q-SIP receives a 526 200 OK response message for a QoS call, it starts a "bidirectional" QoS 527 reservation with the local QoS provider. The callee-side SIP server 528 still participates to Q-SIP signaling but does not talk with a QoS 529 provider. Analogously to the unidirectional case, the caller-side Q-SIP 530 server reads the needed information from the first INVITE and inserts 531 the Q-SIP extension header. The caller-side Q-SIP also keeps the 532 "provisional QoS state", adds the Record-Route header (to remain along 533 the path of the successive requests) and forwards the message. When the 534 first INVITE reaches the callee-side Q-SIP, it installs the "provisional 535 QoS state". When the callee-side Q-SIP receives a 200 OK matching a 536 previously installed "provisional QoS state" it adds the QoS extensions 537 (ER IP address etc) and forwards the 200 OK message. Note that the 538 "provisional QoS state" on the callee-side Q-SIP is removed only when 539 ACK message from the caller is received, in order to handle possible 200 540 OK retransmissions. When caller-side Q-SIP receives the 200 OK it acts 542 Veltri et al. Expires April 2003 11 543 in the same way as for the unidirectional case, but asking the QoS 544 provider for bi-directional reservation. 546 SIP SIP Edge Edge SIP SIP 547 Terminal Server Router Router Server Terminal 548 | | | | | | 549 | INVITE | INVITE | | | INVITE | 550 |--------->|------------------------------->|--------->| 551 | | | | | | 552 |180ringing| | |180ringing|180ringing| 553 |<---------|<-------------------------------|<---------| 554 | | | | | | 555 | | | | 200 OK | 200 OK | 556 | |<-------------------------------|<---------| 557 | | COPS | | | | 558 | |--------->| | | | 559 | | COPS | | | | 560 | 200 OK |<---------| | | | 561 |<---------| | | | | 562 | | | | | | 563 | ACK | ACK | | | ACK | 564 |--------->|------------------------------->|--------->| 565 | | | | | | 566 | Traffic | | | | Traffic | 567 |<====================================================>| 568 | | | | | | 570 Figure 7 _ Q-SIP call signaling flow - bidirectional QoS mode 572 3.2 Q-SIP protocol 574 Regarding the management of QoS SIP sessions within Q-SIP servers, as 575 introduced in the previous sections, two different approaches are 576 considered: 577 i) the Q-SIP servers maintain a "provisional QoS state" during the 578 session setup (stateful Q-SIP), 579 ii) the Q-SIP servers are stateless respect to the QoS sessions during 580 the session setups (stateless Q-SIP). 581 The latter approach will lead to a lighter server implementation, but 582 more information has to be carried in the SIP messages. 583 Note that, considering that it is reasonable that a Q-SIP server will be 584 stateful after the session is setup (to keep track of QoS reservations), 585 we think that the stateful version can be preferred. 586 The next two sections describe separately the two variants. 587 The two variants differ on the manner in which the initial transaction 588 QoS information is kept by Q-SIP servers; in case of "stateful" Q-SIP 589 variant, such initial information is maintained within the server by a 590 "provisional QoS state", while in the "stateless" Q-SIP variant, this 591 information is inserted as parameter in the Record-Route header within 592 the request messages and read from response messages. The latter option 593 is used according to the "RFC 3261" [3], stating that the Record Route 594 parameters can be used as a solution for keeping state in the messages 596 Veltri et al. Expires April 2003 12 597 rather than within the proxies. For this reason all parameters included 598 must be echoed by the user agents (server side) within response 599 messages. 601 3.2.1 Stateful variant of Q-SIP protocol 603 In this variant a "provisional QoS state" is kept in the Q-SIP proxy 604 servers during session setup. 605 When the first Q-SIP server (i.e. the caller-side Q-SIP server) receives 606 a new INVITE message, it inserts the following new field : 608 QoS-Info: *(;) 609 Wherein can be some of: 610 | | | | | caller-media-port> | 613 example: 615 QoS-Info: qos-domain=coritel.it;er-ingress=192.168.77.5; 616 qos-mode=unidirectional 618 By means of the "er-ingress" field the caller-side Q-SIP informs the 619 callee-side Q-SIP server about the IP address of the caller-side ER; 620 instead the "er-egress" field is inserted by the callee-side Q-SIP 621 server for similar reason. This information is used by the Q-SIP servers 622 to specify to the corresponding Q-SIP server the remote endpoint of the 623 reservation. Note that we have assumed the "caller to callee" as an 624 "ingress to egress" reference direction. The "qos-domain" field is used 625 to identify the QoS enabled domain that the reservation has to be 626 accomplished. These wouldn't be strictly required in a intra-domain 627 scenario (one QoS enabled domain); however it could be useful for 628 possible interdomain extensions. 629 The Q-SIP server that initiates the QoS session sets also the "qos-mode" 630 field according to the type of QoS provider it supports (unidirectional 631 or bidirectional) and according to user profiles (in a scenario where 632 unidirectional and bidirectional QoS providers are both possible). 633 A Q-SIP server that receives a message and recognizes that it is for a 634 QoS session, according to a stateful Q-SIP implementation, it may also 635 decide to maintain a per-session provisional QoS state. The last Q-SIP 636 server that stores QoS for that request message will play as callee-side 637 Q-SIP server. 638 When the INVITE message reaches the invited callee, the UA processes the 639 call and if the call is accepted, generates a 200 OK response. 641 Veltri et al. Expires April 2003 13 642 When the 200 OK reaches the callee-side Q-SIP server, the server 643 associates the response to the previously stored provisional QoS state. 644 The registered "qos-mode" specifies the kind of reservation to be 645 applied. In case of unidirectional reservations, it starts the QoS 646 reservation with the QoS provider (i.e. the egress ER). In order to make 647 the QoS request, it needs to retrieve some information (i.e. ingress ER 648 address, media port) from the stored provisional QoS info. When this QoS 649 reservation request/response phase is concluded, the 200 OK messages is 650 opportunely extended with a new "QoS-Info" header as follows: 651 QoS-Info: qos-domain=coritel.it;er-egress=192.168.90.3; 652 qos-mode=unidirectional 653 In case of bidirectional reservations, the callee-side Q-SIP server will 654 not start any QoS reservation and will forward the 200 OK message 655 including the QoS-Info header as shown above, where obviously qos- 656 mode=bidirectional. 658 Even if the QoS reservation for the callee-to-caller flow was not 659 successful, the extension is still inserted to make possible to reserve 660 the QoS for the caller-to-callee flow in a "QoS-Enabled" scenario; 661 however, in this case, the "provisional QoS state" is removed at the 662 receipt of the ACK for the same session. For a "QoS-Assured" model see 663 Appendix A. 664 If there are additional SIP servers handling this response in the path 665 between the callee-side Q-SIP and caller-side Q-SIP servers, they will 666 process it according to standard SIP rules. If they had previously 667 stored some QoS information for that session, they simply remove it. 668 When the message reaches the caller-side Q-SIP server, it associates the 669 message to the stored provisional QoS state and retrieves has all the 670 information to start a QoS reservation (uni- or bi-directional) with the 671 local QoS provider (the ingress ER). Finally, the SIP response is 672 forwarded to the caller. 674 In the Q-SIP mechanism, a key rule is played by the capacity of the Q- 675 SIP servers (both the caller and the callee servers) to gather the 676 necessary information from SIP messages in order to select the 677 appropriate QoS reservation. Particularly the Q-SIP servers have to 678 specify the bandwidth/QoS parameters and the flow characterization 679 parameters (i.e. for traffic policing) for the QoS reservation requests. 680 The Q-SIP servers have to select the appropriate level of bandwidth or 681 service classes, the ingress and egress ERs, and the session 682 identification parameters (i.e. the port number to identify the media 683 flows). This information can be obtained by the Q-SIP directly from the 684 incoming SIP messages. 686 As for the bandwidth or service class that has to be specified to the 687 QoS provider, this is selected on the basis of the type of media and 688 codecs specified by the end UAs (within the SDP body) and/or according 689 to the particular user profile. For most audio codecs it can be 690 relatively easy to prepare a mapping table of codecs and required 691 bandwidths, for RTP streams. For video codecs this is not so simple 692 therefore one could have to rely on user profiles. In Appendix C, it is 694 Veltri et al. Expires April 2003 14 695 reported an example of mapping table for well known audio codecs. It 696 reports both the payload bit rates and the required bandwidths (taking 697 into account the IPv4 and IPv6 headers). 699 As for the session identification, in general different filters can be 700 used. For example, RSVP defines for basic flow filtering the destination 701 IP address, the transport protocol identifier and (optionally) a 702 transport address, i.e., in case of UDP/TCP, the destination port. 703 In our architecture we use a three-fields filter composed by the source 704 address, the destination address and the destination port. This 705 information can be extracted from the INVITE/200 OK messages directly by 706 the caller-side/callee-side Q-SIP servers. 707 Note that the caller address and port information needed to setup the 708 QoS for both directions are found within INVITE messages. Instead, the 709 reservation is made by the caller-side and callee-side Q-SIP servers 710 when they receive the 200 OK message. The callee media address and port 711 is extracted directly from the 200 OK message (the callee address from 712 the callee-side Q-SIP server and the callee address and port from the 713 caller-side Q-SIP server). 715 The Q-SIP call setup flow is shown in Figure 6 and Figure 7. 717 The tear down procedure is triggered by the receiving of the BYE and 200 718 OK messages at the caller-side /callee-side Q-SIP servers. When a Q-SIP 719 server receives the BYE request associated to a session with QoS, it 720 requests the releasing of the bandwidth for that session to the QoS 721 provider. If required, the resource details could be retrieved from a 722 stored "QoS state". In Appendix B there is an example of "provisional 723 QoS state" that can be associated to a new QoS setup transaction and the 724 "QoS state" that can be associated to the active QoS call. 725 When a BYE request matches one of the stored call-leg, the Q-SIP server 726 releases the resources by interacting with the QoS provider and frees 727 the QoS state. If a BYE message gets lost due to a terminal failure, the 728 session tear-down should be initiated (automatically) by the other SIP 729 terminal as a result of a session time-out. Another possibility to force 730 a resource release procedure is based on the use of time-outs and INFO 731 method ([7]) by the Q-SIP servers, as described in section 5. Note that 732 this mechanism can be used only if the UA supports the INFO method. 733 In order to ensure that the SIP signaling will cross the Q-SIP servers, 734 the Record-Route and Route headers are used. For this reason, the Q-SIP 735 server inserts the Record-Route header within requests for all QoS SIP 736 sessions. 738 Appendix D reports an example of Q-SIP messages using the stateful Q-SIP 739 variant. 741 3.2.2 Stateless variant of the Q-SIP protocol 743 Let us consider the stateless Q-SIP specification, i.e. the Q-SIP 744 variant that let the server stateless during the call setups. For this 745 reason, a mechanism is needed in order to allow a Q-SIP server that 746 receives a 200 OK message to retrieve all the information needed to 748 Veltri et al. Expires April 2003 15 749 setup a reservation. Instead of maintaining a provisional QoS state 750 within the Q-SIP server, the QoS information is included in the SIP 751 request messages and retrieved when intercepting the responses. The 752 insertion mechanism has been defined in such a way that does not require 753 the collaboration of SIP UAs (in order to allow the use of QoS-unaware 754 SIP UAs). For such objective, the Q-SIP makes use of the Route/Record- 755 Route SIP mechanism. According to the SIP specification, the Record- 756 Route header is returned opaquely by the called UA within the response 757 messages. Such functionality allows the Q-SIP server to "store" the QoS 758 information as Record-Route header parameter and to obtain it back in 759 the response messages. 760 When the caller-side Q-SIP receives an INVITE request, as specified for 761 a stateful Q-SIP server, it appends the previously defined QoS-Info 762 header and the Record-Route header. 763 The Record-Route header is now extended with the following Q-SIP 764 parameters: 765 Record-Route: "<" ;*(;) ">" 767 Wherein can be of the form of: 768 *(;< qos-param>) 770 example: 771 Record-Route: 778 Note that, although it could appear redundant, both the qos-info Record- 779 Route parameter and the QoS-Info header is inserted by the Q-SIP. 780 In the same way, the callee-side Q-SIP server appends its Record-Route 781 header, that becomes: 783 Record-Route: , 786 789 When the INVITE message reaches the callee host, the UA processes the 790 call, and, at last, generates the 200 OK response (if the call is 791 accepted). 792 If the UA is not aware of Q-SIP it simply discards the Q-SIP header (the 793 QoS-Info header if it is not removed by the callee-side Q-SIP server) 794 when forming the new response message. According to the SIP protocol, 795 the fields that it has to copy from the INVITE message are the Via, To, 796 From, CSeq, Call-ID and Record-Route header. 797 When the 200 OK reaches the callee-side Q-SIP server, the Record-Route 798 field is read and the QoS session information are extracted. In case of 799 unidirectional reservation mode a QoS request for the callee-to-caller 800 direction is started. When this QoS reservation request/response phase 802 Veltri et al. Expires April 2003 16 803 is concluded and the resource is reserved, a QoS state may be stored and 804 the 200 OK messages is relayed toward the caller. 805 As for the stateful Q-SIP variant, a new QoS-Info header in added to the 806 response. 807 Even if the QoS reservation for the callee-to-caller flow was not 808 successful, or a bidirectional reservation is handled, this field is 809 still inserted to inform the callee-side Q-SIP about the callee QoS end- 810 point. The complete procedure for a "QoS-Assured" model is described in 811 Appendix A. 812 It is very important to remember that the use of the previously defined 813 Record-Route parameters lets each Q-SIP server extract all information 814 needed for the QoS reservation directly from the SIP message that it is 815 processing. This mechanism allows the Q-SIP not to keep per session 816 information until a QoS call is completely installed and can be used in 817 light Q-SIP implementations. 818 This "QoS state" is instead needed when the call setup is completed for 819 a robust tear-down procedure, for accounting and for resource control. 821 Regarding the caller media end-point (caller address and port), although 822 it is extracted from INVITE messages, it is used for making the 823 reservation when receiving the 200 OK message. Since no state is 824 maintained within the servers, both caller-side and callee-side Q-SIP 825 servers also store caller media end-point information within the Record- 826 Route qos-param (see previous examples). 828 Appendix E reports an example of Q-SIP messages using the stateless Q- 829 SIP variant. 831 4. Q-SIP syntax and rules 833 4.1 Syntax 835 QoS-Info Header = "QoS-Info" HCOLON qos-param *(SEMI qos-param) 836 qos-param = qos-mode / er-ingress / er-egress / 837 qos-domain / other 838 qos-domain = "qos-domain=" domain-name 839 er-ingress = "er-ingress=" ingress-ER-address 840 er-egress = "er-egress=" egress-ER-address 841 qos-mode = "qos-mode=" qos-reservation 842 qos-reservation = "unidirectional" / "bidirectional" 843 domain-name = alphanum / alphanum *( alphanum / "-") alphanum 844 caller-media-addr= "caller-media-addr=" caller-addr 845 caller-media-port= "caller-media-port=" media-port 846 other = token [EQUAL alphanum] 848 Record-Route Header= "Record-Route" HCOLON "<"server-uri; 849 qos-info *(;next_param)">" 850 qos-info = qos-param *(;qos-param) 852 Veltri et al. Expires April 2003 17 853 4.2 Rules 855 Every Q-SIP server MUST be able to act as both caller-side and callee- 856 side Q-SIP servers. 858 QoS-Info Header : it is inserted by the caller-side Q-SIP server when 859 processing INVITE messages, and by the callee-side Q-SIP server when 860 processing 200 OK response messages (referring to an INVITE method). 861 The QoS-Info Header may carry both mandatory and optional parameters. 862 Table I reports for each QoS-Info parameter, whether it is mandatory (m) 863 or optional (o) for caller-side and callee-side Q-SIP servers. 864 These rules apply for both stateful and stateless Q-SIP variants. 865 If no qos-mode is specified, the unidirectional reservation mode is 866 supposed. 868 | Parameter | caller-side Q-SIP | callee-side Q-SIP | 869 |--------------------+-------------------+-------------------| 870 | qos-domain | o | o | 871 | er-ingress | m | - | 872 | er-egress | - | m | 873 | qos-mode | o | o | 874 | caller-media-addr | o | - | 875 | caller-media-port | o | - | 876 | | | | 878 Table I - Mandatory and optional QoS-Info Header parameters 880 Record-Route Header : it is inserted by both caller-side and callee-side 881 Q-SIP servers by both stateful or stateless Q-SIP variants. The Record- 882 Route guaranties that the Q-SIP remains along the SIP signaling path. 883 The "qos-info" Record-Route parameter is inserted only for the stateless 884 Q-SIP variant. The implementation of the stateless Q-SIP extension 885 variant is not mandatory for a Q-SIP server; however if it is 886 implemented, all stateless Q-SIP rules MUST be satisfied. 887 Both caller-side and callee-side Q-SIP servers MUST insert the "qos- 888 info" Record-Route parameter. 889 Table II reports for each QoS-Info parameter, whether it is mandatory 890 (m) or optional (o) for caller-side and callee-side Q-SIP servers. 891 These rules apply for both stateful and stateless Q-SIP variants. 892 If no qos-mode is specified, the unidirectional reservation mode is 893 supposed. 895 | Parameter | caller-side Q-SIP | callee-side Q-SIP | 896 |--------------------+-------------------+-------------------| 897 | qos-domain | o | o | 898 | er-ingress | m | - | 899 | er-egress | - | m | 900 | qos-mode | o | o | 901 | caller-media-addr | m | m | 902 | caller-media-port | m | m | 903 | | | | 905 Veltri et al. Expires April 2003 18 906 Table II - Mandatory and optional qos-info parameters for Record-Route 907 Header 909 5. Use of INFO method for robust tear-down procedure 911 The tear-down of resources must be robust with respect to events like 912 terminal failures or network failures that may prevent the Q-SIP server 913 to receive the BYE message closing the session. A way to assure the 914 correct release of the previously reserved resources is the use of time- 915 outs and INFO method ([7]). 916 A Q-SIP proxy can use timeouts associated with the call session. The 917 timeout expiration triggers the generation of an INFO request matching 918 the characteristics of the dialog ID associated to the call state and 919 directed to the controlled SIP terminal (User Agent). This request and 920 its associated responses can be used as a "ping" for the call session 921 activity. 922 The INFO request, generated by the client side of the proxy, is sent 923 only to the local UA for a call session that the outbound Q-SIP proxy 924 has reserved resources to, so only local additional signaling messages 925 are generated. 926 The server side of the UA can respond with several messages that are 927 interpreted and used by the Q-SIP proxy: 929 UA response to INFO Q-SIP Proxy action 930 ------------------------------------------------------------------- 931 200OK : Call/transaction exists renew timeout associated 932 481 : Call/transaction doesn't release reserved resources 933 exist 934 405 : Method not allowed/supported don't use this mechanism for 935 this call session 936 501 : Not implemented don't use this mechanism for 937 this UA 939 The chose of the time-out value is left to vendor implementation. 941 6. SIP Terminals 943 Although it has been supposed that the SIP user UAs are not aware of the 944 Q-SIP reservation mechanism, Q-SIP aware UAs can be also considered 945 (Figure 4). 946 Q-SIP aware UAs should simply include Q-SIP as described in the previous 947 sections. In that case, the UAs could directly request QoS reservation 948 to the QoS providers and the Q-SIP signaling would transparently bypass 949 any SIP or Q-SIP proxy server. Moreover the architecture is fully 950 compatible also for calls starting from Q-SIP aware UAs and directed to 951 standard SIP UAs with Q-SIP proxy servers, and vice-versa (Figure 5). 953 Veltri et al. Expires April 2003 19 954 7. Q-SIP Servers 956 A basic design choice in the design of a SIP proxy server is whether to 957 make it stateful or stateless. Being stateful means that it keeps a 958 record of active SIP session and the processing of SIP messages can 959 depend on the session status. Being stateless means that each message is 960 processed by itself with no relations with previous messages of the same 961 session. A stateful server of course is more powerful as it can better 962 handle additional aspects (like for example policy and accounting), but 963 the SIP protocol has been designed so that stateless server can work as 964 well. 965 Looking at the proposed approach, we note that the Q-SIP server handles 966 the QoS for a SIP session, by making a reservation in the QoS enabled 967 network. The Q-SIP server has to care about this reservation, for 968 example the resources must be properly released when the session is 969 closed. For this reason we believe that the Q-SIP server must be 970 stateful once the session has been established. 971 Nevertheless, we have designed our Q-SIP extensions preserving the SIP 972 design goals: is possible either to store state information in Q-SIP 973 server during the session establishment or to carry all the needed 974 information in the SIP messages. 976 8. Security Considerations 978 A proxy that performs resource reservations triggered by the reception 979 of unauthenticated requests can be an easy target of a DoS (Denial of 980 Service) attack. Requests for a possible QoS session SHOULD be 981 authenticated. 982 In order to assure the correct handling of the QoS service offered to 983 the UA by the outbound Q-SIP server, proxy authentication SHOULD be 984 used. In this way, the Q-SIP before initiates a QoS session and 985 reserving resources, can use the authorization/authentication mechanism 986 to assure the right access control and availability of the service in 987 accord to the user profile. 988 The user profile can contain user password and the type of service that 989 the user is enabled to, so it can be used as authentication and resource 990 reservation support. 992 9. Change log and prototype implementation 994 This version v1 is the second version of the Q-SIP draft. The changes 995 with respect to previous version v0 are: 997 - QoS state information in SIP messages is now carried in Record 998 Route headers instead of Via headers (according to the change in 999 SIP specification of [3]) 1000 - The stateful variant of the Q-SIP protocol has been specified. 1002 Veltri et al. Expires April 2003 20 1003 - The use of bidirectional reservation (according to 2.1.)is 1004 supported 1005 - The use of INFO messages to support robust tear-down of resources 1006 has bee specified 1007 - A discussion on QoS assured model (Appendix A) has been added 1009 A prototype implementation of a Q-SIP server is available [6]. 1011 The messages reported in Appendix D are extracted from the current 1012 implementation in a simple successful SIP call that involves two Q-SIP 1013 servers. 1015 Appendix A: QoS-Enabled vs. QoS-Assured 1017 In the previous part of the document the QoS enabled resource 1018 reservation is considered. In a QoS assured scenario [1] the QoS can be 1019 a precondition to the establishment of the session indicated by SIP. An 1020 UA can use the Q-SIP proxy reservation mechanism in order to reserve 1021 resources before beginning the session. In this scenario a UA can be 1022 preconfigured to use the mechanism here described. Various situations 1023 depending on the type of reservation handled by the proxy are discussed. 1024 The UAs involved in this scenario supports the qos preconditions as 1025 specified in [1] and the reliable provisional responses [8]. A 1026 precondition is an information written in the SDP describing the SIP 1027 session. By means of this information the terminals can communicate each 1028 other that they want a QoS reservation and then that the reservation has 1029 been established. 1030 The main idea is the following. A Q-SIP server receives a message for a 1031 local UA containing preconditions (i.e. stating that QoS reservation is 1032 needed). The Q-SIP server will take care of the resource reservation and 1033 change the preconditions in the message according to the reservation 1034 done. In other words the Q-SIP will ensure that preconditions are met 1035 with no need for the UAs to setup the QoS reservations.. 1036 This can be considered an alternative scenario to those presented in [1] 1037 that consider only UAs supporting RSVP. 1039 In the following sections A.1 and A.2 the technical details of the 1040 possible interaction of the QoS assured scenario described in [1] and 1041 the Q-SIP architecture are provided. 1043 Note that in the described scenarios the Q-SIP server needs to modify 1044 the SDP inside the SIP message. Another more elegant solution could be 1045 to insert a new SIP header to report the result of the resource 1046 reservation to the UA. The UA will then change the SDP as described in 1047 [1]. The drawback in this case is that the UAs need to supports the new 1048 defined header. 1050 A.1 Q-SIP using unidirectional QoS Network reservation 1052 A.1.1 Bidirectional e2e reservation sender initiated 1054 Veltri et al. Expires April 2003 21 1055 Figure 8 reports the signaling flow with the most important 1056 interactions. 1058 SIP Q-SIP Edge Edge Q-SIP SIP 1059 UA(A) Server A Router Router Server B UA(B) 1060 | | | | | | 1061 |INVITE(SDP1)| INVITE(SDP1) |INVITE(SDP1) | 1062 |----------->|------------------------------->|------------>| 1063 | | | | | | 1064 | | | | | 183(SDP2) | 1065 | | | | COPS |<------------| 1066 | | | |<---------| | 1067 | | | | COPS | | 1068 | | | |--------->| | 1069 | | | |183(SDP3) | | 1070 | |<-------------------------------| | 1071 | | COPS | | | | 1072 | |--------->| | | | 1073 | | COPS | | | | 1074 | 183(SDP4) |<---------| | | | 1075 |<-----------| | | | | 1076 | PRACK | PRACK | PRACK | 1077 |----------->|------------------------------->|------------>| 1078 | | 200 OK (PRACK) | | 1079 |<-----------|<-------------------------------|<------------| 1080 |UPDATE(SDP5)| UPDATE(SDP5) | UPDATE(SDP5)| 1081 |----------->|------------------------------->|------------>| 1082 | | 200 OK (UPDATE) | | 1083 |<-----------|<-------------------------------|<------------| 1084 | | 180 Ringing | | 1085 |<-----------|<-------------------------------|<------------| 1086 | | 200 OK (INVITE) | | 1087 |<-----------|<-------------------------------|<------------| 1088 | Traffic | | | | Traffic | 1089 |<=========================================================>| 1090 | | | | | | 1092 Figure 8 _ Bidirectional e2e successful reservation using Q-SIP in the 1093 QoS assured sender initiated case 1095 When Q-SIP A receives an INVITE containing an offer from a UA that is 1096 preconfigured (user profile defined) to use it for the resource 1097 reservation in a QoS assured mode, it reads SDP1. If it contains the SDP 1098 attribute "a=des:" with the "qos" precondition_type, "mandatory" 1099 strength tag, "e2e" status type and "send" or "sendrecv" direction-tag 1100 the Q-SIP starts a QoS session as described previously. Almost the same 1101 for Q-SIP B, that relies in the user profile of the called UA (UA (B)) 1102 to start the QoS session. The difference is even in the direction-tag 1103 that must be "recv" or "sendrecv" to initiate the QoS session. 1104 UA (B) relies in Q-SIP proxy QoS handling (preconfigured for proxy 1105 resource reservation) so it responds with a reliable 183(SDP2) if it 1106 wants to set-up the call with QoS. If for any reason it does not want, 1108 Veltri et al. Expires April 2003 22 1109 it responds with a 580 Failure that is used also by the Q-SIP proxies to 1110 terminate the pending QoS session. 1111 When the Q-SIP B receives the 183(SDP2), it has all the information to 1112 perform the resource reservation and depending on the result it changes 1113 the SDP: if reservation (callee to caller) fails it sends SDP2 (SDP not 1114 changed), if is OK sends SDP3(SDP changed!!!). 1115 If the Q-SIP A receives a 183(SDP2), it understands that the reservation 1116 in the callee to caller direction is failed , terminates the initiated 1117 QoS session and proxies the message to the UA(A). If the message 1118 received is a 183(SDP3), it performs the resource reservation. If the 1119 reservation is successful the Q-SIP changes SDP3 in SDP4, else it 1120 terminates the QoS session and does not change the SDP3. 1121 If the UA(A) receives a 183 with SDP4 it sends immediately the new offer 1122 in SDP5 using the UPDATE message. In any other case it assumes that the 1123 QoS session has failed so it sends SDP6 in the UPDATE message. 1124 Q-SIP A and Q-SIP B do nothing in case of UPDATE with SDP5, in case of 1125 SDP6 the Q-SIP B releases the resources previously reserved. 1126 Hereafter the relevant parts of the SDPs are listed: 1128 SDP1: a=curr: qos e2e none 1129 a=des: qos mandatory e2e sendrecv 1131 SDP2: a=curr: qos e2e none 1132 a=des: qos mandatory e2e sendrecv 1133 a=conf: qos e2e recv 1135 SDP3: a=curr: qos e2e send 1136 a=des: qos mandatory e2e sendrecv 1137 a=conf: qos e2e recv 1139 SDP4: a=curr: qos e2e sendrecv 1140 a=des: qos mandatory e2e sendrecv 1141 a=conf: qos e2e recv 1143 SDP5: a=curr: qos e2e sendrecv 1144 a=des: qos mandatory e2e sendrecv 1146 SDP6: a=curr: qos e2e **** 1147 a=des: qos failure e2e sendrecv 1149 A.1.2 Unidirectional e2e reservation sender initiated 1151 In these cases only one flow is required to have the QoS support as 1152 reported on the SDP1 (the offer). 1154 Caller to callee QoS e2e required: 1156 SDP1: a=curr: qos e2e none 1157 a=des: qos mandatory e2e send 1159 Veltri et al. Expires April 2003 23 1160 Q-SIP A handles the reservation and if it successful it changes the SDP 1161 of the answer: SDP2 in SDP3. Q-SIP B only use Q-SIP extensions to 1162 transmit to Q-SIP A the callee-side ER. 1164 SDP2: a=curr: qos e2e none 1165 a=des: qos mandatory e2e recv 1167 SDP3: a=curr: qos e2e recv 1168 a=des: qos mandatory e2e recv 1170 Callee to caller QoS e2e required: 1172 SDP1: a=curr: qos e2e none 1173 a=des: qos mandatory e2e recv 1175 Q-SIP A only uses Q-SIP extensions to transmit to Q-SIP B the caller ER. 1176 Q-SIP B handles the reservation and if it is successful it changes SDP2 1177 in SDP3 as reported below. 1179 SDP2: a=curr: qos e2e none 1180 a=des: qos mandatory e2e send 1182 SDP3: a=curr: qos e2e send 1183 a=des: qos mandatory e2e send 1185 In all cases if a failure situation occurs the UA(A) sends the UPDATE 1186 with the new offer containing SDP4. 1188 SDP3: a=curr: qos e2e **** 1189 a=des: qos failure e2e **** 1191 Note: **** mean send or recv. 1193 A.1.3 Bidirectional e2e reservation receiver initiated 1195 In this case the first INVITE does not contain an SDP so the Q-SIP 1196 entities cannot distinguish at this point if the session is to be set or 1197 not with QoS. Even in this case the outbound proxy for the caller and 1198 the callee side may remain on the signaling path using the Record-Route 1199 support. As reported in Figure 9 it is the UA(B) that initiates the 1200 offer-answer exchange sending the reliable 183(SDP1). 1201 When Q-SIP B receives the 183(SDP1) and an associated QoS session does 1202 not exist, it initiates the QoS session and uses the Q-SIP extensions to 1203 transmit the callee-side ER. 1204 When Q-SIP A receives the 183(SDP1) reporting also the extensions, it 1205 initiates the QoS session. 1206 UA(A) knows that it is configured with the Q-SIP for supporting the QoS 1207 so it can send immediately the PRACK(SDP2)[7][8]. 1208 In the Q-SIP A the receipt of the PRACK(SDP2) for a QoS session of a UA 1209 that is configured to have the QoS assured support triggers the 1210 reservation (now we have all the needed information). If the reservation 1211 is successful this is reported inside SDP3 and Q-SIP A uses the Q-SIP 1213 Veltri et al. Expires April 2003 24 1214 extensions to transmit to the callee-side Q-SIP proxy the caller-side 1215 ER, if not the SDP is removed (compliant with [1]) and the QoS session 1216 is terminated. 1217 If the Q-SIP B receives PRACK without SDP2 and the extensions, it 1218 removes the QoS session and simply proxies the message. If the message 1219 received is PRACK(SDP3) with the extensions, it tries to reserve the 1220 resources requested. If the reservation is successful this is reported 1221 inside SDP4, if not the SDP is removed, the QoS session is terminated 1222 and the message is forwarder to UA(B). 1223 Hereafter the relevant parts of the SDPs involved are reported: 1225 SDP1: a=curr: qos e2e none 1226 a=des: qos mandatory e2e sendrecv 1227 a=conf: qos e2e recv 1229 SDP2: a=curr: qos e2e none 1230 a=des: qos mandatory e2e sendrecv 1232 SDP3: a=curr: qos e2e send 1233 a=des: qos mandatory e2e sendrecv 1234 SDP4: a=curr: qos e2e sendrecv 1235 a=des: qos mandatory e2e sendrecv 1237 Note that the if UA(B) receives SDP4, it knows that the preconditions 1238 are meet so it can immediately send 200 OK (of PRACK) and the 180 1239 Ringing without the need of an UPDATE. The UA(A) receives the 180 1240 Ringing that assures that the preconditions are met. 1242 Veltri et al. Expires April 2003 25 1243 SIP Q-SIP Edge Edge Q-SIP SIP 1244 UA(A) Server A Router Router Server B UA(B) 1245 | | | | | | 1246 | INVITE | INVITE | INVITE | 1247 |----------->|------------------------------->|------------>| 1248 | | | | | | 1249 | | | | | 183(SDP1) | 1250 | | 183(SDP1) |<------------| 1251 | 183(SDP1) |<-------------------------------| | 1252 |<-----------| | | | | 1253 | PRACK(SDP2)| | | | | 1254 |----------->| COPS | | | | 1255 | |--------->| | | | 1256 | | COPS | | | | 1257 | |<---------| | | | 1258 | | PRACK(SDP3) | | 1259 | |------------------------------->| | 1260 | | | | COPS | | 1261 | | | |<---------| | 1262 | | | | COPS | | 1263 | | | |--------->| PRACK(SDP4) | 1264 | | | | |------------>| 1265 | | 200 OK (PRACK) | | 1266 |<-----------|<-------------------------------|<------------| 1267 | | 180 Ringing | | 1268 |<-----------|<-------------------------------|<------------| 1269 | | 200 OK (INVITE) | | 1270 |<-----------|<-------------------------------|<------------| 1271 | Traffic | | | | Traffic | 1272 |<=========================================================>| 1273 | | | | | | 1275 Figure 9 _ Bidirectional e2e successful reservation using Q-SIP in the 1276 QoS assured receiver initiated case 1278 If the PRACK received by UA(B) does not contain SDP, we have the 1279 precondition failure case that is handled according to [7]. 1281 A.1.4 Unidirectional e2e reservation receiver initiated 1283 In these cases only one flow is required to have the QoS support as 1284 reported on the SDP1 (the offer). 1286 Callee to caller QoS e2e required: 1288 SDP1: a=curr: qos e2e none 1289 a=des: qos mandatory e2e send 1291 Veltri et al. Expires April 2003 26 1292 Q-SIP A only uses Q-SIP extensions to transmit to Q-SIP B the callee- 1293 side ER. Q-SIP B handles the reservation and if it successful change SDP 1294 of the answer: SDP2 in SDP3. If not it removes the SDP from the PRACK. 1296 SDP2: a=curr: qos e2e none 1297 a=des: qos mandatory e2e recv 1299 SDP3: a=curr: qos e2e recv 1300 a=des: qos mandatory e2e recv 1302 Caller to callee QoS e2e required: 1304 SDP1: a=curr: qos e2e none 1305 a=des: qos mandatory e2e recv 1306 a=conf: qos e2e recv 1308 Q-SIP B only uses Q-SIP extensions to transmit to Q-SIP B the caller ER 1309 using the 183(SDP1). Q-SIP A handles the reservation and if it is 1310 successful, change SDP2 in SDP3 as reported below. If not removes the 1311 SDP from the PRACK. 1313 SDP2: a=curr: qos e2e none 1314 a=des: qos mandatory e2e send 1316 SDP3: a=curr: qos e2e send 1317 a=des: qos mandatory e2e send 1319 A.2 Q-SIP using bidirectional QoS Network reservation 1321 A.2.1 Bidirectional e2e reservation sender initiated 1323 In the Figure 10 is reported the signaling flow with the most important 1324 entity interactions. The main differences are that only one of the Q-SIP 1325 (the caller one) is involved in the network reservation and the other 1326 one needs only as support to have the needed information. Here below are 1327 listed the entity interactions: 1329 Q-SIP A receives INVITE(SDP1) from an UA that is enabled to receive the 1330 QoS assured support: Initiate an QoS session and proxy the message 1331 containing the Q-SIP extensions for this case. 1332 Q-SIP B receives INVITE(SDP1) with the Q-SIP extensions: It installs the 1333 QoS session and proxy the message. 1334 UA(B) receives INVITE(SDP1) and it is preconfigured to have the QoS 1335 proxy support (if need), so it sends the 183(SDP2). 1336 Q-SIP B receives 183(SDP2) for an existing QoS session: It inserts the 1337 Q-SIP extensions and proxy the message. 1338 Q-SIP A receives 183(SDP2) for an existing QoS session: It handle 1339 reservation; if it is successful change SDP in SDP3, if not don't 1340 change-it. 1341 When UA(A) receives 183(SDP3) it sends PRACK and UPDATE(SDP4). In the 1342 other cases (preconditions failure), it sends PRACK and UPDATE(SDP5). 1344 Veltri et al. Expires April 2003 27 1345 The SDPs involved in the signaling flow: 1347 SDP1: a=curr: qos e2e none 1348 a=des: qos mandatory e2e sendrecv 1350 SDP2: a=curr: qos e2e none 1351 a=des: qos mandatory e2e sendrecv 1352 a=conf: qos e2e recv 1354 SDP3: a=curr: qos e2e sendrecv 1355 a=des: qos mandatory e2e sendrecv 1356 a=conf: qos e2e recv 1358 SDP4: a=curr: qos e2e sendrecv 1359 a=des: qos mandatory e2e sendrecv 1361 SDP5: a=curr: qos e2e none 1362 a=des: qos failure e2e sendrecv 1364 Veltri et al. Expires April 2003 28 1365 SIP Q-SIP Edge Edge Q-SIP SIP 1366 UA(A) Server A Router Router Server B UA(B) 1367 | | | | | | 1368 |INVITE(SDP1)| INVITE(SDP1) |INVITE(SDP1) | 1369 |----------->|------------------------------->|------------>| 1370 | | | | | | 1371 | | | | | 183(SDP2) | 1372 | | | | |<------------| 1373 | | | |183(SDP2) | | 1374 | |<-------------------------------| | 1375 | | COPS | | | | 1376 | |--------->| | | | 1377 | | COPS | | | | 1378 | 183(SDP3) |<---------| | | | 1379 |<-----------| | | | | 1380 | PRACK | PRACK | PRACK | 1381 |----------->|------------------------------->|------------>| 1382 | | 200 OK (PRACK) | | 1383 |<-----------|<-------------------------------|<------------| 1384 |UPDATE(SDP4)| UPDATE(SDP4) | UPDATE(SDP4)| 1385 |----------->|------------------------------->|------------>| 1386 | | 200 OK (UPDATE) | | 1387 |<-----------|<-------------------------------|<------------| 1388 | | 180 Ringing | | 1389 |<-----------|<-------------------------------|<------------| 1390 | | 200 OK (INVITE) | | 1391 |<-----------|<-------------------------------|<------------| 1392 | Traffic | | | | Traffic | 1393 |<=========================================================>| 1394 | | | | | | 1396 Figure 10 _ Bidirectional e2e successful reservation using Q-SIP in the 1397 QoS assured sender initiated case 1399 Note that the QoS session on the Q-SIP B is removed when the PRACK for 1400 the 183 is received. 1402 A.2.2 Bidirectional e2e reservation receiver initiated 1404 The difference from the 3.1.3 is that only one reservation is done by 1405 the caller-side Q-SIP and the Q-SIP B only supports this reservation by 1406 giving the callee-side ER. 1407 Here after the SDP involved in the signaling messages (shown in the 1408 Figure 11) are reported: 1410 SDP1: a=curr: qos e2e none 1411 a=des: qos mandatory e2e sendrecv 1412 a=conf: qos e2e recv 1414 SDP2: a=curr: qos e2e none 1415 a=des: qos mandatory e2e sendrecv 1417 Veltri et al. Expires April 2003 29 1418 SDP3: a=curr: qos e2e sendrecv 1419 a=des: qos mandatory e2e sendrecv 1421 SIP Q-SIP Edge Edge Q-SIP SIP 1422 UA(A) Server A Router Router Server B UA(B) 1423 | | | | | | 1424 | INVITE | INVITE | INVITE | 1425 |----------->|------------------------------->|------------>| 1426 | | | | | | 1427 | | | | | 183(SDP1) | 1428 | | 183(SDP1) |<------------| 1429 | 183(SDP1) |<-------------------------------| | 1430 |<-----------| | | | | 1431 | PRACK(SDP2)| | | | | 1432 |----------->| COPS | | | | 1433 | |--------->| | | | 1434 | | COPS | | | | 1435 | |<---------| | | | 1436 | | PRACK(SDP3) | | 1437 | |------------------------------->|------------>| 1438 | | 200 OK (PRACK) | | 1439 |<-----------|<-------------------------------|<------------| 1440 | | 180 Ringing | | 1441 |<-----------|<-------------------------------|<------------| 1442 | | 200 OK (INVITE) | | 1443 |<-----------|<-------------------------------|<------------| 1444 | Traffic | | | | Traffic | 1445 |<=========================================================>| 1446 | | | | | | 1448 Figure 11 _ Bidirectional e2e successful reservation using Q-SIP in the 1449 QoS assured receiver initiated case 1451 Appendix B - Description of the QoS State 1453 A possible implementation of the QoS State : 1455 ::= 1456 1457 1458 1459 1461 The Call-Identification has the following format: 1463 ::= 1465 Veltri et al. Expires April 2003 30 1466 The type of state has the following format: 1468 < Type of state > ::= 1470 The scope of the reservation has the following format : 1472 ::= 1473 1474 1475 1477 The type of the reservation has the following format : 1479 ::= 1481 The Session identification filter has the following format: 1483 ::= 1484 [] 1485 1486 1488 Note that the source/destination port is to intend as the ingress ports 1489 for the media flow (the port where the User Agent wait for the media 1490 data). According to the assumptions made before, that the QoS state in 1491 our scenario refers to a unidirectional or bidirectional flow inside the 1492 core network. 1494 Appendix C - Payload type vs. bandwidth 1496 |---------|---------|---------|-----------------------| 1497 | | Payload | Payload | | 1498 | Code | Type | Bit-Rate| Bandwidth (IPv4/IPv6) | 1499 | | | (kbit/s)| (kbit/s) | 1500 |---------|---------|---------|-----------------------| 1501 | PCMU | 0 | 64 | 81.6 / 88 | 1502 | 1016 | 1 | 16 | 33.6 / 40 | 1503 | G.721 | 2 | 32 | 49.6 / 56 | 1504 | GSM | 3 | 13 | 30.6 / 37 | 1505 | G.723 | 4 | 6.3 | 23.9 / 30.3 | 1506 | DV14 | 5 | 32 | 49.6 / 56 | 1507 | DV14(2) | 6 | 64 | 81.6 / 88 | 1508 | LPC | 7 | 2.4 | 20 / 26.6 | 1509 | PCMA | 8 | 64 | 81.6 / 88 | 1510 | G.722 | 9 | 64 | 81.6 / 88 | 1511 | MPA | 14 | 32 | 49.6 / 56 | 1512 | G.728 | 15 | 16 | 33.6 / 40 | 1513 | G.729 | 18 | 8 | 25.6 / 32 | 1514 | | | | | 1515 |---------|---------|---------|-----------------------| 1517 Veltri et al. Expires April 2003 31 1518 Appendix D - Examples of Q-SIP messages 1520 Examples of Q-SIP messages in the successful reservation scenario using 1521 the "provisional QoS state" approach are depicted in the picture 1522 hereafter. The messages are numbered from M1 to M18. Only the messages 1523 sent by the proxy servers are reported in detail. 1525 1526 eulero.coritel.it galileo.coritel.it 1527 gauss.coritel.it maxwell.coritel.it 1528 User A Proxy 1 Proxy 2 User B 1529 | INVITE M1 | | | 1530 |--------------->| INVITE M2 | | 1531 | |--------------->| INVITE M3 | 1532 | | |--------------->| 1533 | 180ringing M6 | 180ringing M5 | 180ringing M4 | 1534 |<---------------|<---------------|<---------------| 1535 | | | 200 OK M7 | 1536 | | 200 OK M8 |<---------------| 1537 | 200 OK M9 |<---------------| | 1538 |<---------------| | | 1539 | ACK M10 | ACK M11 | ACK M12 | 1540 |--------------->|--------------->|--------------->| 1541 | RTP Media | 1542 |<================================================>| 1543 | | | BYE M13 | 1544 | | BYE M14 |<---------------| 1545 | BYE M15 |<---------------| | 1546 |<---------------| | | 1547 | 200 OK M16 | 200 OK M17 | 200 OK M18 | 1548 |--------------->|--------------->|--------------->| 1550 Veltri et al. Expires April 2003 32 1551 Message M2 (INVITE from Proxy 1 to Proxy 2): 1553 INVITE sip:UserB@maxwell.coritel.it SIP/2.0 1554 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=z9hG4bKzksdfse3re 1555 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKzkdui3jfid 1556 From: UserA;tag=938108741 1557 To: UserB 1558 Server: Coritel SIP Server 1.0 1559 Record-Route: 1560 QoS-Info: qos-domain=coritel.it;er-ingress=192.168.90.3;qos-mode= 1561 unidirectional 1562 Call-ID: 1234567001@eulero.coritel.it 1563 Max-Forwards: 69 1564 CSeq: 1 INVITE 1565 Contact: 1566 Content-Type: application/sdp 1567 Content-Length: 148 1569 v=0 1570 o=UserA 2890844526 2890844526 IN IP4 eulero.coritel.it 1571 s=Session SDP 1572 c=IN IP4 151.100.37.131 1573 t=0 0 1574 m=audio 49172 RTP/AVP 0 1575 a=rtpmap:0 PCMU/8000 1577 Message M3 (INVITE from Proxy 2 to User B): 1579 INVITE sip:UserB@galileo.coritel.it:5060 SIP/2.0 1580 Via: SIP/2.0/UDP maxwell.coritel.it:5060;branch=z9hG4bKkvjg1kk5gf 1581 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=z9hG4bKzksdfse3re 1582 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKzkdui3jfid 1583 From: UserA;tag=938108741 1584 To: UserB 1585 Server: Coritel SIP Server 1.0 1586 Server: Coritel SIP Server 1.0 1587 Record-Route: , 1588 Call-ID: 1234567001@eulero.coritel.it 1589 Max-Forwards: 68 1590 CSeq: 1 INVITE 1591 Contact: 1592 Content-Type: application/sdp 1593 Content-Length: 148 1595 v=0 1596 o=UserA 2890844526 2890844526 IN IP4 eulero.coritel.it 1597 s=Session SDP 1598 c=IN IP4 151.100.37.131 1599 t=0 0 1600 m=audio 49172 RTP/AVP 0 1601 a=rtpmap:0 PCMU/8000 1603 Veltri et al. Expires April 2003 33 1604 Message M8 (200 OK from Proxy 2 to Proxy1): 1606 SIP/2.0 200 OK 1607 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=z9hG4bKzksdfse3re 1608 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKzkdui3jfid 1609 From: UserA;tag=938108741 1610 To: UserB;tag=181046899 1611 Record-Route: , 1612 QoS-Info: qos-domain=coritel.it;er-egress=192.168.90.9;qos-mode= 1613 unidirectional 1614 Call-ID: 1234567001@eulero.coritel.it 1615 CSeq: 1 INVITE 1616 Contact: 1617 Content-Type: application/sdp 1618 Content-Length: 148 1620 v=0 1621 o=UserB 2890844527 2890844527 IN IP4 galileo.coritel.it 1622 s=Session SDP 1623 c=IN IP4 151.100.37.143 1624 t=0 0 1625 m=audio 3456 RTP/AVP 0 1626 a=rtpmap:0 PCMU/8000 1628 Veltri et al. Expires April 2003 34 1629 Message M9 (200 OK from Proxy 1 to User A): 1631 SIP/2.0 200 OK 1632 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKzkdui3jfid 1633 From: UserA;tag=938108741 1634 To: UserB;tag=181046899 1635 Record-Route: , 1636 Call-ID: 1234567001@eulero.coritel.it 1637 CSeq: 1 INVITE 1638 Contact: 1639 Content-Type: application/sdp 1640 Content-Length: 148 1642 v=0 1643 o=UserB 2890844527 2890844527 IN IP4 galileo.coritel.it 1644 s=Session SDP 1645 c=IN IP4 151.100.37.143 1646 t=0 0 1647 m=audio 3456 RTP/AVP 0 1648 a=rtpmap:0 PCMU/8000 1650 Message M14 (BYE from Proxy 2 to Proxy 1): 1652 BYE sip:UserA@gauss.coritel.it SIP/2.0 1653 Via: SIP/2.0/UDP maxwell.coritel.it:5060;branch=z9hG4bKljfds7df8s 1654 Via: SIP/2.0/UDP galileo.coritel.it:5060;branch=z9hG4bKpinfjd6h3h 1655 Route: 1656 From: UserB;tag=181046899 1657 To: UserA;tag=938108741 1658 Server: Coritel SIP Server 1.0 1659 Call-ID: 1234567001@eulero.coritel.it 1660 Max-Forwards: 69 1661 CSeq: 1 BYE 1662 Content-Length: 0 1664 Message M15 (BYE from Proxy 1 to user A) 1666 BYE sip:UserA@eulero.coritel.it:5060 SIP/2.0 1667 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=z9hG4bKlj2kl4jdik 1668 Via: SIP/2.0/UDP maxwell.coritel.it:5060;branch=z9hG4bKljfds7df8s 1669 Via: SIP/2.0/UDP galileo.coritel.it:5060;branch=z9hG4bKpinfjd6h3h From: 1670 UserB;tag=181046899 1671 To: UserA;tag=938108741 1672 Server: Coritel SIP Server 1.0 1673 Server: Coritel SIP Server 1.0 1674 Call-ID: 1234567001@eulero.coritel.it 1675 Max-Forwards: 68 1676 CSeq: 1 BYE 1677 Content-Length: 0 1679 Veltri et al. Expires April 2003 35 1680 Appendix E 1682 Examples of Q-SIP messages in the successful reservation scenario 1683 keeping "provisional QoS state" in the messages are depicted in the 1684 picture hereafter. The messages are numbered from M1 to M18. Only the 1685 messages sent by the proxy servers are reported in detail. 1687 1688 eulero.coritel.it galileo.coritel.it 1689 gauss.coritel.it maxwell.coritel.it 1690 User A Proxy 1 Proxy 2 User B 1691 | INVITE M1 | | | 1692 |--------------->| INVITE M2 | | 1693 | |--------------->| INVITE M3 | 1694 | | |--------------->| 1695 | 180ringing M6 | 180ringing M5 | 180ringing M4 | 1696 |<---------------|<---------------|<---------------| 1697 | | | 200 OK M7 | 1698 | | 200 OK M8 |<---------------| 1699 | 200 OK M9 |<---------------| | 1700 |<---------------| | | 1701 | ACK M10 | ACK M11 | ACK M12 | 1702 |--------------->|--------------->|--------------->| 1703 | RTP Media | 1704 |<================================================>| 1705 | | | BYE M13 | 1706 | | BYE M14 |<---------------| 1707 | BYE M15 |<---------------| | 1708 |<---------------| | | 1709 | 200 OK M16 | 200 OK M17 | 200 OK M18 | 1710 |--------------->|--------------->|--------------->| 1712 Veltri et al. Expires April 2003 36 1713 Message M2 (INVITE from Proxy 1 to Proxy 2): 1715 INVITE sip:UserB@maxwell.coritel.it SIP/2.0 1716 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=z9hG4bKicd7op8ocx 1717 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKjasldjl2oi 1718 From: UserA;tag=734578133 1719 To: UserB 1720 Server: Coritel SIP Server 1.0 1721 Record-Route: 1724 QoS-Info: qos-domain=coritel.it;er-ingress=192.168.90.3;qos-mode= 1725 unidirectional 1726 Call-ID: 1234567801@eulero.coritel.it 1727 Max-Forwards: 69 1728 CSeq: 1 INVITE 1729 Contact: 1730 Content-Type: application/sdp 1731 Content-Length: 148 1733 v=0 1734 o=UserA 2890844526 2890844526 IN IP4 eulero.coritel.it 1735 s=Session SDP 1736 c=IN IP4 151.100.37.131 1737 t=0 0 1738 m=audio 49172 RTP/AVP 0 1739 a=rtpmap:0 PCMU/8000 1741 Veltri et al. Expires April 2003 37 1742 Message M3 (INVITE from Proxy 2 to User B): 1744 INVITE sip:UserB@galileo.coritel.it:5060 SIP/2.0 1745 Via: SIP/2.0/UDP maxwell.coritel.it:5060;branch=z9hG4bKsdfpogir4r 1746 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=z9hG4bKicd7op8ocx 1747 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKjasldjl2oi 1748 From: UserA;tag=734578133 1749 To: UserB 1750 Server: Coritel SIP Server 1.0 1751 Server: Coritel SIP Server 1.0 1752 Record-Route: , 1755 1757 Call-ID: 1234567801@eulero.coritel.it 1758 Max-Forwards: 68 1759 CSeq: 1 INVITE 1760 Contact: 1761 Content-Type: application/sdp 1762 Content-Length: 148 1764 v=0 1765 o=UserA 2890844526 2890844526 IN IP4 eulero.coritel.it 1766 s=Session SDP 1767 c=IN IP4 151.100.37.131 1768 t=0 0 1769 m=audio 49172 RTP/AVP 0 1770 a=rtpmap:0 PCMU/8000 1772 Veltri et al. Expires April 2003 38 1773 Message M8 (200 OK from Proxy 2 to Proxy 1): 1775 SIP/2.0 200 OK 1776 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=z9hG4bKicd7op8ocx 1777 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKjasldjl2oi 1778 From: UserA;tag=734578133 1779 To: UserB;tag=234857984 1780 Record-Route: , 1783 1785 QoS-Info: qos-domain=coritel.it;er-egress=192.168.90.9;qos-mode= 1786 unidirectional 1787 Call-ID: 1234567801@eulero.coritel.it 1788 CSeq: 1 INVITE 1789 Contact: 1790 Content-Type: application/sdp 1791 Content-Length: 148 1793 v=0 1794 o=UserB 2890844527 2890844527 IN IP4 galileo.coritel.it 1795 s=Session SDP 1796 c=IN IP4 151.100.37.143 1797 t=0 0 1798 m=audio 3456 RTP/AVP 0 1799 a=rtpmap:0 PCMU/8000 1801 Veltri et al. Expires April 2003 39 1802 Message M9 (200 OK from Proxy 1 to User A): 1804 SIP/2.0 200 OK 1805 Via: SIP/2.0/UDP eulero.coritel.it:5060;branch=z9hG4bKjasldjl2oi 1806 From: UserA;tag=734578133 1807 To: UserB;tag=234857984 1808 Record-Route: , 1811 1813 Call-ID: 1234567801@eulero.coritel.it 1814 CSeq: 1 INVITE 1815 Contact: 1816 Content-Type: application/sdp 1817 Content-Length: 148 1819 v=0 1820 o=UserB 2890844527 2890844527 IN IP4 galileo.coritel.it 1821 s=Session SDP 1822 c=IN IP4 151.100.37.143 1823 t=0 0 1824 m=audio 3456 RTP/AVP 0 1825 a=rtpmap:0 PCMU/8000 1827 Message M14 (BYE from Proxy 2 to Proxy 1): 1829 BYE sip:UserA@gauss.coritel.it SIP/2.0 1830 Via: SIP/2.0/UDP maxwell.coritel.it:5060;branch=asdfhkjksdf3kjj2f 1831 Via: SIP/2.0/UDP galileo.coritel.it:5060;branch=sdlfhk4f3gmpsdfo3 1832 Route: 1835 From: UserB;tag=234857984 1836 To: UserA;tag=734578133 1837 Server: Coritel SIP Server 1.0 1838 Call-ID: 1234567801@eulero.coritel.it 1839 Max-Forwards: 69 1840 CSeq: 1 BYE 1841 Content-Length: 0 1843 Veltri et al. Expires April 2003 40 1844 Message M15 (BYE from Proxy 1 to user A) 1846 BYE sip:UserA@eulero.coritel.it:5060 SIP/2.0 1847 Via: SIP/2.0/UDP gauss.coritel.it:5060;branch=h2kerpuighber5d4l 1848 Via: SIP/2.0/UDP maxwell.coritel.it:5060;branch=asdfhkjksdf3kjj2f 1849 Via: SIP/2.0/UDP galileo.coritel.it:5060;branch=sdlfhk4f3gmpsdfo3 1850 From: UserB;tag=234857984 1851 To: UserA;tag=734578133 1852 Server: Coritel SIP Server 1.0 1853 Server: Coritel SIP Server 1.0 1854 Call-ID: 1234567801@eulero.coritel.it 1855 Max-Forwards: 68 1856 CSeq: 1 BYE 1857 Content-Length: 0 1859 References 1861 [1] G. Camarillo et al. "Integration of Resource Management and 1862 SIP", IETF Internet Draft , 1863 April 2002, Work in Progress. 1864 [2] IETF WG NSIS - Next Step In Signaling 1865 http://www.ietf.org/html.charters/nsis-charter.html 1866 [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1867 Peterson, R. Sparks, M. Handley, E. Schooler, " SIP: Session Initiation 1868 Protocol", IETF RFC 3261, June 2002. 1869 [4] D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. 1870 Sastry, "The COPS (Common Open Policy Service) Protocol", IETF RFC 2748, 1871 January 2000. 1872 [5] S. Salsano " COPS Usage for Diffserv Resource Allocation (COPS- 1873 DRA) ", draft-salsano-cops-dra-00.txt, October 2001, work in progress 1874 [6] CoRiTeL The Q-SIP project http://www.coritel.it/projects/qsip 1875 [7] S. Donovan, "The SIP INFO method", RFC 2976, October 2000. 1876 [8] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional 1877 Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 1878 2002. 1880 Veltri et al. Expires April 2003 41 1881 Author Information and Acknoledgements 1883 Special thanks to Jocelyn Fiorina for his comments and suggestions and 1884 for the work on the prototype implementation for the previous version of 1885 the draft. 1887 Luca Veltri 1888 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni 1889 Via Anagnina, 203 1890 00040 Roma - ITALY 1891 email: veltri@coritel.it 1893 Stefano Salsano 1894 DIE - University of Rome "Tor Vergata" 1895 Viale Politecnico, 1 1896 00133 Roma - ITALY 1897 email: stefano.salsano@uniroma2.it 1899 Donald Papalilo 1900 CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni 1901 Via Anagnina, 203 1902 00040 Roma - ITALY 1903 email: papalilo@coritel.it 1905 Veltri et al. Expires April 2003 42