idnits 2.17.1 draft-salsano-sipping-siphandover-solution-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 750. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) == There are 2 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 506: '...t such procedure MUST be reversible si...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (May 7, 2008) is 5834 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group S. Salsano 3 Internet-Draft Univ. of Rome Tor Vergata 4 Intended status: Informational S. Niccolini 5 Expires: November 8, 2008 NEC 6 L. Veltri 7 Univ. of Parma 8 A. Polidoro 9 Univ. of Rome Tor Vergata 10 May 7, 2008 12 A solution for vertical handover of multimedia sessions using SIP 13 draft-salsano-sipping-siphandover-solution-02 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 8, 2008. 40 Abstract 42 This document proposes a solution for handling vertical handovers 43 among different network technologies using SIP, fulfilling a set of 44 requirements discussed in the document "Requirements for vertical 45 handover of multimedia sessions using SIP" 46 (draft-niccolini-sipping-siphandover-03). The solution requires a 47 new header field (named "Handover") and a new parameter in the Via 48 header field (named "MMID"). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Architecture of the proposed solution . . . . . . . . . . . . 5 56 3. Signalling procedures . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Off-call mobility: Location Update (LU) Registration 58 procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1.1. Extensions to SIP specifications . . . . . . . . . . . 8 60 3.2. User Registration procedure . . . . . . . . . . . . . . . 9 61 3.2.1. Extensions to SIP specifications . . . . . . . . . . . 9 62 3.3. Session Establishment procedure . . . . . . . . . . . . . 10 63 3.3.1. Extensions to SIP specifications . . . . . . . . . . . 11 64 3.4. On-Call Mobility: Handover procedure . . . . . . . . . . . 11 65 3.4.1. Extensions to SIP specifications . . . . . . . . . . . 13 67 4. Routing of requests and responses . . . . . . . . . . . . . . 14 68 4.1. Use of Contact header field . . . . . . . . . . . . . . . 14 69 4.2. MMID parameter in Via header field . . . . . . . . . . . . 15 71 5. Handover: header . . . . . . . . . . . . . . . . . . . . . . . 16 73 6. Decoupling user level registration and terminal level 74 registration . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 7. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9. Security considerations . . . . . . . . . . . . . . . . . . . 20 82 10. Informative References . . . . . . . . . . . . . . . . . . . . 21 84 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 87 Intellectual Property and Copyright Statements . . . . . . . . . . 24 89 1. Introduction 91 A set of requirements for vertical handover using SIP has been 92 discussed in [niccolini-sip-HO]. Figure 1 reports the scenario under 93 consideration. In short, the requirement is to allow a Mobile Host 94 to roam over different access networks using both public and private 95 IP addresses, minimizing service disruption due to mobility, without 96 relying on Corresponent Host functionality and even hiding to the 97 Correspondent Host the movements of the Mobile Host. In this 98 document we describe a possible solution to these requirements (and 99 all the other ones listed in [niccolini-sip-HO]). The solution 100 requires a new header field (named "Handover") and a new parameter in 101 the Via header field (named "MMID"). The new header and new 102 parameter will only be added and processed by the entities directly 103 involved in the management of the mobility, with no impact on other 104 SIP entities. 106 +-------+ 107 | AN1 |-----+ 108 ----| | NAT | +--------+ 109 / +-------+-----+ |Corresp.| 110 +-------+ __________ | Host 1 | 111 | Mobile| +-------+ / \ +--------+ 112 | Host | | AN2 | / \ 113 +-------+ ----| | | INTERNET | 114 + - - - + \ / 115 \__________/ 116 \ +-------+ +--------+ 117 ----| AN3 |-----+ +-----|Corresp.| 118 | | NAT | | NAT | Host 2 | 119 +-------+-----+ +-----+--------+ 121 Figure 1: Scenario for Vertical Handover 123 In Section 2 the architectural elements of the solution are 124 presented. Section 3 describe the signalling procedures to realize 125 the mobility management (both off-call and on-call) and the 126 establishment of sessions. Section 4 and Section 5 specify the new 127 parameters in the Via header field (named "MMID") and the new header 128 field (named "Handover") that are required by the proposed solution. 130 2. Architecture of the proposed solution 132 The elements of the proposed solution are shown in Figure 2. We 133 assume that a Mobile Host (MH) is communicating with a Correspondent 134 Host (CH). The MMS is the Mobility Management Server which is able 135 to handle user mobility across different access networks and to 136 perform the handover. The MMS cooperates with the MMC (Mobility 137 Management Client) which resides on the Mobile Host. Figure 2 shows 138 that NAT boxes can be inserted between the MH and the MMS. Figure 2 139 shows a standard SIP trapezoid with the additional elements of this 140 solution (MMS and MMC). Such figure is just for explanation 141 purposes, the solution proposed here is not depending on the 142 communication following the standard SIP trapezoid to work. 144 The MMS is an "anchor point" for the media flows which are 145 transmitted over the wireless access networks directed to (and coming 146 from) the MH. When the MMC in the MH detects that a handover is 147 needed, it will request the handover to the MMS (via a SIP message) 148 over the "target" network. Then the MMS will update its media proxy 149 and will start transmitting and receiving the media over the target 150 network (details are provided in the next section). Note that the 151 entire handover procedure is handled by the MH and the MMS, letting 152 the CT (and other SIP intermediate nodes) completely unaware of what 153 is occurring. For the sake of simplicity, we only describe here the 154 solution considering a single centralized MMS. In real life, the MMS 155 functionality may need to be distributed for scalability and 156 reliability reasons. 158 The Mobility Management Client can be implemented (as shown in 159 Figure 2) as a separate entity running on the MH that masquerades all 160 mobility and NAT traversal functionality by relaying both signaling 161 and media flows. In this case the SIP User Agent sees the MMC as 162 default "outbound proxy" (which means that the UA will send all SIP 163 message to the MMC) and it has no knowledge of the handovers. 164 Existing SIP UAs can be easily supported/reused without any changes. 165 A different solution would be to integrate the MMC functionality 166 within the UA, saving resources of the MH. These two solutions only 167 differ in the internal implementation, while there is no difference 168 in the external behavior of the procedures. 170 Classical SIP UA +-------+ +-------+ 171 Registration | MH's |---| CH's | 172 ................> | Proxy | | Proxy | 173 . /+-------+ +-------+\ 174 . / \ 175 . / \ 176 . / \ 177 Mobile Host . +-----+ +----+ 178 +-------+ . | MMS |---------------------------| CH | 179 |+-----+|<... +-----+ +----+ 180 || UA || / A 181 |+-----+| / . 182 |+-----+| +-----+ / . 183 || MMC ||---------| NAT |/ . Mobile Host Mobility 184 |+-----+| `+-----+ . 185 +---A---+ . 186 . . 187 . . 188 ..................... 190 Figure 2: Architecture of the proposed solution 192 3. Signalling procedures 194 This section describes the specific procedures for mobility 195 management (off-call and on-call) and shows how the canonical SIP 196 procedures (user registration and session establishment) are realized 197 under the proposed solution. The procedure for mobility management 198 related to the off-call part is meant to be used by the MH (UA+MMC) 199 to tell the MMS about its current selected/active interface (or to 200 communicate changes to such selection) when not in a call, for this 201 we use regular REGISTER sent from the MMC to the MMS. The on-call 202 mobility management related to the on-call part is meant to be used 203 by the MH (UA+MMC) to tell the MMS about a change in its current 204 selected/active interface when in a call, for this we use regular 205 REGISTER sent from the MMC to the MMS with an additional "Handover" 206 header which contains the reference to the active session(s) to which 207 the handover is referred. In both cases an additional parameter to 208 be added to the "Via" header for correct routing of responses to the 209 MMC is needed and used. 211 3.1. Off-call mobility: Location Update (LU) Registration procedure 213 The "Location Update" (LU) Registration is the basic mobility 214 procedure that allows a MH to notify the MMS about its "position" (or 215 better about its IP address) and select the currently preferred 216 interface for sending/receiving SIP signaling and media flows. The 217 sequence diagram of this procedure is shown in Figure 3. The MMC in 218 the MH sends a standard REGISTER to the MMS over the selected/active 219 interface. This procedure is activated at the start up of the MH (or 220 when the MH first enters in a coverage area), or whenever the MH 221 wants to change the selected/active interface if it is under coverage 222 of more than one network. We can refer to this procedure as "off- 223 call" mobility management because we assume that the MH is not 224 engaged in a call. If the MH is engaged in a call, the handover 225 procedure will be executed (see Section 3.4). When the 200 OK is 226 received, a "keep-in-touch" mechanism is activated on that interface 227 (and deactivated on the previous interface if needed) in order to 228 keep the pinhole in the NAT open. Various techniques could be used 229 for this purpose; we use periodic SIP REGISTER messages from MMC to 230 MMS. 232 +-------+ +-------+ +-------+ +-------+ 233 | U A | | MMC | | MMS | | Proxy | 234 +-------+ +-------+ +-------+ +-------+ 235 | | | | 236 | | LU REGISTER | | 237 | |============>| | 238 | | | | 239 | | 200 OK | | 240 | |<============| | 241 | | | | 243 Figure 3: Location Update Procedure 245 As result of the Location Update Registration procedure, the MMS 246 becomes aware of the current position (i.e. IP address and port) of 247 the MH, and can correctly route any new request or response messages 248 addressed to the mobile UA (even across a NAT box). For each 249 registered user the MMS stores the IP address and port from which it 250 received the "Location Update" (LU) REGISTER. This information can 251 be stored by the MMS in a table that we call "MMS mobility database" 252 containing the MMS state. Such table is depicted in Figure 4. 254 ---------------------------------------------- 255 | User(terminal) | IP/port | 256 ---------------------------------------------- 257 | user@domain.com | 160.80.81.23:45678 | 258 | user2@domain.com | 87.3.235.212:23458 | 259 | ... | ... | 260 ---------------------------------------------- 262 Figure 4: MMS mobility database 264 3.1.1. Extensions to SIP specifications 266 The Location Update Registration procedure does not require specific 267 extensions to the current SIP specification. A LU REGISTER will have 268 the MMS as target SIP URI in the request line. If the MMS only 269 handles LU REGISTERs there is no problem. If the MMS also handles 270 normal user registration REGISTER (i.e. it acts also as a SIP 271 registrar) the MMS needs to identify LU REGISTERs from normal user 272 REGISTER. In this case a specific SIP URI can be associated to the 273 LU REGISTER messages. 275 Anyway as will be discussed in Section 4, the MMC will add the new 276 parameter "MMID" in the Via header of the REGISTER, in order to have 277 the responses routed to current location (IP addresses) of the MH. 279 3.2. User Registration procedure 281 This procedure consists in the UA registration with its own SIP 282 Registrar server. The sequence diagram of this procedure is 283 described in Figure 5. As any other SIP message, when the UA sends 284 its own registration request to the SIP Registrar, the message is 285 sent by the UA to the MMC which is seen as outbound proxy. The MMC 286 forwards it to the MMS. Acting on behalf of the MH, the MMS will 287 forward the registration to the SIP Registrar, which will update the 288 contact address associated with the user's AoR (that is the public 289 user identifier). When forwarding the REGISTER message, the MMS 290 modifies the Contact header in such a way it becomes the new 291 "contact" for the user. This is required in order to force the 292 routing through the MMS of all further requests addressed to the 293 user. Such mangling of the contact URL should be unique and 294 reversible. Details on how to encode the user AoR in the new contact 295 are provided below in Section 4.1. From now on, only the MMS will 296 keep track of the MH movements, while the SIP Registrar will just 297 believe that the MH location is the IP address of the MMS. 299 +-------+ +-------+ +-------+ +---------+ 300 | U A | | MMC | | MMS | |MH'sProxy| 301 +-------+ +-------+ +-------+ +---------+ 302 | REGISTER | | | 303 |============>| | | 304 | | REGISTER | | 305 | |============>| | 306 | | | REGISTER | 307 | | |=============>| 308 | | | 200 OK | 309 | | |<=============| 310 | | 200 OK | | 311 | |<============| | 312 | 200 OK | | | 313 |<============| | | 314 | | | | 316 Figure 5: User Registration 318 3.2.1. Extensions to SIP specifications 320 The User Registration procedure requires that the MMS rewrites the 321 contact address as will be described Section 4.1. Anyway, this does 322 not need to be subject of specification as it only concerns the MMS. 323 All other entities will simply handle the rewritten contact according 324 to current SIP specification. As will be discussed in Section 4, the 325 MMC will add the new parameter "MMID" in the Via header of the 326 REGISTER messages, in order to have the responses routed to current 327 location (IP addresses) of the MH. 329 3.3. Session Establishment procedure 331 The session establishment procedure consists in a standard SIP 332 session setup procedure. All session establishment messages for MH 333 are handled by the MMS. Before relaying an INVITE request sent by 334 the caller and the corresponding 200 OK response sent by the callee 335 the MMS modifies the corresponding SDP bodies in order to act as RTP 336 proxy for media flows in both directions. This is needed to 337 correctly handle NAT traversal in the path towards the MH, and it is 338 done by using the symmetric RTP approach. Once the session is 339 established, the media packets start to flow over the selected 340 wireless interface. Figure 6 shows a session establishment from CH 341 to MH. 343 UserAgent MMC MMS MH's Proxy CH's Proxy CH 344 | | | | | | 345 | | | | | INVITE | 346 | | | | INVITE |<===========| 347 | | | INVITE |<===========| | 348 | | INVITE |<===========| | | 349 | INVITE |<===========| | | | 350 |<===========| | | | | 351 | 200 OK | | | | | 352 |===========>| 200 OK | | | | 353 | |===========>| 200 OK | | | 354 | | |=========== | 200 OK | | 355 | | | |===========>| 200 OK | 356 | | | | |===========>| 357 | | | | | ACK | 358 | | | | ACK |<===========| 359 | | | ACK |<===========| | 360 | | ACK |<===========| | | 361 | ACK |<===========| | | | 362 |<===========| | | | | 363 | | | | | | 365 Figure 6: Session Establishment 367 The MMS needs to keep a state information related to the active flows 368 as it is performing a media relay functionality. In order to 369 correclty perform the handover procedure, we require that this state 370 information is accessible using the current call as key. SIP 371 identifies a call by means of the Call-ID, the From and To header 372 fields. Therefore the MMS maintains an "MMS call database", see 373 Figure 7. For each call and for each media flow the information of 374 two "legs" (MH-MMS and CH-MMS) need to be stored . For each leg the 375 local and remote IP addresses and port of the media flows are stored. 376 As shown in Figure 7 the legs are stored as "originating" leg (i.e. 377 the leg connecting the MMS with the user in the "From" header) and 378 terminating leg (i.e. the leg connecting the MMS with the user in the 379 "To" header). In Figure 7 only one media media flow per call, while 380 in general more than one media flow can be associated to a call. 382 ------------------------------------------------------------------- 383 | Call | Originating leg | Terminating leg | 384 ------------------------------------------------------------------- 385 |Call-ID:F16@192 |Local: |Local: | 386 |From:|160.80.81.23:4345 |160.80.81.23:4569 | 387 |;tag=871 |Remote: |Remote: | 388 |To: |151.2.82.21:3824 |87.3.235.212:3458 | 389 |;tag=345 | | | 390 ------------------------------------------------------------------- 391 |Call-ID:xcv@1sfdsf.sdf |Local: |Local: | 392 |From:|160.80.81.23:8732 |160.80.81.23:7745 | 393 |;tag=sgf |Remote: |Remote: | 394 |To: |87.3.233.12:23458 |151.8.48.2:3456 | 395 |;tag=dsw | | | 396 ------------------------------------------------------------------- 398 Figure 7: MMS call database 400 3.3.1. Extensions to SIP specifications 402 The User Registration procedure requires that the MMS rewrites the 403 contact address as will be described Section 4.1. Actually, this is 404 not a matter of specification as it only concerns the MMS. All other 405 entities will simply handle the rewritten contact according to 406 current SIP specification. As will be discussed in Section 4, the 407 MMC will add the new parameter "MMID" in the Via header of the 408 REGISTER messages, in order to have the responses routed to current 409 location (IP addresses) of the MH. 411 3.4. On-Call Mobility: Handover procedure 413 The on-call mobility management procedure takes place when the UA 414 identifies the need for handoff during an ongoing session. In our 415 proposal, all the handover signaling messages can be exchanged on the 416 target network (this approach is commonly referred to as "forward" 417 handover). Therefore the handover can be performed even if the 418 communication on the old network is interrupted abruptly. The 419 handover procedure (see Figure 8) is initiated by the MH. The MMC in 420 the MH sends an "HandOver" (HO) REGISTER over the target network 421 interface addressed to the MMS. Differently from a "Location Update" 422 (LU) REGISTER, the "HandOver" (HO) REGISTER request contains in the 423 message body the reference to the active session(s) to which the 424 handover is referred. At the same time, the MH starts duplicating 425 the outgoing media packets on both interfaces (unless the old 426 interface has gone down). As soon as the MMS receives the "HandOver" 427 (HO) REGISTER, it starts accepting packets coming from the new 428 interface and discarding the ones coming from the old interface for 429 the active session(s) to be handed over. Then it sends back the 200 430 OK to the MMC and it starts sending the media packets directed to the 431 MH using the new interface. Thanks to the fact that the terminal has 432 already started sending the packets on the new interface, the 433 duration of the handover is minimized. The most critical issue is 434 that the "HandOver" (HO) REGISTER could be lost for any reason, 435 delaying the handoff procedure. The standard SIP procedure foresees 436 that the client performs a set of retransmission of the "HandOver" 437 (HO) REGISTER if the 200 OK is not received back. The SIP 438 specification suggests a default value of the T1 retransmission 439 timeout equal to 500 ms, that is doubled on each retransmission (up 440 to the value of T2 which by default is 4 s). The duration of the 441 ritrasmission is 64*T1. However this is not compatible with a 442 reasonable performance of the handover in case of the loss of the 443 "HandOver" (HO) REGISTER. We propose the the timers for the 444 "HandOver" (HO) REGISTER procedure should be set to lower values, 445 like for example: T1 = 50 ms, T2 = 250 ms. On the MH side, the MMC 446 will stop duplicating the packets on both interfaces as soon as the 447 200 OK is received or the first media packet is received on the new 448 interface. Note that if the media packet is received, but no 200 OK 449 message, the MMC will still continue sending the "HandOver" (HO) 450 REGISTER until the REGISTER transaction expires. 452 +-------+ +-------+ +-------+ +-------+ 453 | U A | | MMC | | MMS | | Proxy | 454 +-------+ +-------+ +-------+ +-------+ 455 | | | | 456 | | HO REGISTER | | 457 | |============>| | 458 | | | | 459 | | 200 OK | | 460 | |<============| | 461 | | | | 463 Figure 8: Handover REGISTER 465 3.4.1. Extensions to SIP specifications 467 The on-call mobility management needs the definition of a new header 468 field (see Section 5) to carry the identification of the call(s) to 469 be handed over. This header field will be added by the MMC and 470 handled by the MMS. Moreover, as will be discussed in Section 4, the 471 MMC will add the new parameter "MMID" in the Via header of the 472 REGISTER messages, in order to have the responses routed to current 473 location (IP addresses) of the MH. 475 4. Routing of requests and responses 477 In this section we detail how SIP messages are routed among the 478 different entities. The challenge is to deliver incoming SIP 479 requests and SIP responses to the MH, nonwithstanding its mobility. 481 As for incoming SIP requests, when the UA in the MH performs the User 482 Registration procedure (Section 3.2) the MMS rewrites the Contact 483 header filed so that it points to the MMS itself. Therefore incoming 484 requests for the MH will be forwarded by the SIP incoming proxy to 485 the MMS. Similarly when outgoing requests are sent from the MH to a 486 Correspondent Host the MMS will rewrite the Contact header so that 487 the CH will consider the MMS as the destination of future requests to 488 the MH. When incoming requests arrive to the MMS, the MMS will 489 forward them to the current IP address of the MH, as updated by the 490 MH using the Location Update procedure (Section 3.1). 492 As for responses to outgoing SIP requests sent by the MH, the MMS 493 adds a new parameter in the Via header field (see Section 4.2). This 494 parameter is used by the MMS itself to route the response. 496 4.1. Use of Contact header field 498 The solution foresees that the MMS rewrites the Contact header when 499 forwarding outgoing SIP requests coming from the MH. The rewritten 500 contact address will have as host part the IP address (or domain 501 name) of the MMS, and as username part an hint to the original 502 contact address. The procedure that binds the new username to the 503 original contact address is just a matter of the MMS and is 504 completely left to MMS implementation. There is no need to 505 standardize the procedure for rewriting the Contact header. The only 506 requirement is that such procedure MUST be reversible since the MMS 507 needs to be able to rebuild the original Contact header field when 508 receiving SIP requests addressed to the rewritten contact address. 509 Obviously, the rewritten Contact header will be compatible with SIP 510 specifications, so that all other involved entities will simply need 511 to behave according to the standard. 513 For example, a possible solution is that the MMS generates a pseudo- 514 random string that is stored in a local database and used as key to 515 retrieve the original Contact header field. Another possible 516 solution is to embed the original contact in the rewritten contact so 517 that no state information needs to be stored in the MMS. For 518 example, assume that user's AoR is user@domain.com and the original 519 Contact header inserted by the UA is: 521 Contact: 522 where x.y.w.z is the current IP address of the MH. The MMS can 523 rewrite the contact as follows: 525 Contact: 527 Where MMS_x.y.w.z is the IP address of the MMS, "TOKEN-" is a string 528 that can be set by the MMS and "/" is used as escape character. When 529 receiving an incoming request with the request URI corresponding to 530 the above contact, the MMS will extract the original contact address 531 user@x.y.w.z:5080 and will forward the message according to the 532 information contained in its MMS mobility database. 534 4.2. MMID parameter in Via header field 536 According to SIP specification, each node in the request delivery 537 chain adds a Via header field with its own IP address when forwarding 538 the request, in order to be included in the response delivery chain. 539 We propose that the MMC adds an additional parameter to the Via 540 header. This parameter is called MMID (Mobility Management 541 IDentifier) and it carries the identifier of the MH. The MMID 542 parameter is used as an indication that the originator of the request 543 is a mobile host and it could change its IP address even during the 544 transaction. Therefore the value of the MMID will be used as a key 545 into the MMS mobility database, in order to find the current IP 546 address to send the response. With this mechanism, the solution is 547 able to deal in a seamless way with an handover performed during a 548 session establishment. 550 As an example, a Via header sent by the MMC to the MMS may look like 551 the following: 553 Via: SIP/2.0/UDP x.y.w.z;branch=z9h;MMID=user@domain.com 555 5. Handover: header 557 When the MH needs to perform the handover during an active call, the 558 MMC will send an "HandOver" (HO) REGISTER to the MMS. These message 559 will perform the update of the MMS mobility database likewise the 560 "Location Update" (LU) REGISTER, but in addition it will start the 561 handover of the media flows belonging to the call. We insert a new 562 header in the "HandOver" (HO) REGISTER, which includes the reference 563 to the call to be handed over. The new header name will be 564 "Handover:" and it will carry the Call-ID and the two tags, in a 565 similar way to the Join header [refs.rfc3911] or to the Replaces 566 header [refs.rfc3891]. In particular the parameters that carry the 567 tags are called "req-tag" and "other-tag". 569 Handover: sxdfv20000513@host.domain.com; req-tag=erfg; other-tag=wdfe 571 The MMC requesting the handover will insert in the "req-tag" the tag 572 corresponding to the MH in the INVITE transaction that originated the 573 call (i.e. the From: tag if the call was originated by the MH or the 574 To: tag if the call was originated by the CH). By comparing this 575 information with the MMS call database (Figure 7), the MMS will be 576 able to understand on which of the two legs of the call the handover 577 has been requested. 579 6. Decoupling user level registration and terminal level registration 581 One optional requirement discussed in [niccolini-sip-HO] was to allow 582 the decoupling of "user level" registration and "terminal level" 583 mobility. As an example a user with AOR "sip:user@domain.com" should 584 be allowed to use different terminals (i.e. Mobile Hosts supporting 585 the handover solutions as well as normal SIP terminals). In this 586 document we did not explicilty consider this requirement, we assumed 587 that the Mobile Host is identified by an AOR "sip:user@domain.com" 588 and therefore this AOR can be used for only one Mobile Host. 590 We only mention here that this requirement can be addressed in 591 straighforward way by introducing the concept of a Terminal 592 identifier, distinct by the user AoR. The MMC can use this Terminal 593 identifier inserting it in the MMID parameters in Via header. The 594 terminal identifier will become the key to retrieve information 595 related to the MH in the MMS, rather then using the user's AoR. 597 7. Related work 599 The general problem of continuity of multimedia sessions is currently 600 heavily discussed in 3GPP and it was agreed to be studied in 601 timeframe of Release 8. The handover that this document refers to is 602 referred to as PS-PS session continuity in 3GPP terminology. 3GPP is 603 considering the usage of an intermediate element in order to handle 604 PS-PS multimedia session continuity as written in 3GPP Technical 605 Report 23.893. The usage of such intermediate element is also the 606 core point of the solution presented in [Salsano08], [Salsano07]. 607 Also the scenarios currently under discussion are inline with the 608 scenario depicted in Section 2 (please note that the scenarios 609 discussed in 3GPP are currently a superset of the one depicted in 610 this document). 612 8. Conclusions 614 This document presented a possible solution to the set of 615 requirements discussed in [niccolini-sip-HO]. The solution requires 616 a new header field (named "Handover") in order to support the 617 handover of media flows during an active call and a new parameters to 618 the Via header field in order to allow the correct routing of SIP 619 responses to the MH even during an handover. The standardization of 620 these two elements would allow the open interoperability of MHs and 621 MMS. We note that variants of the described solution have been 622 successfully implemented in some testbeds by the authors (see for 623 example [Salsano08]). The motivation of this work assumes even more 624 relevance if 3GPP interest in this kind of solutions is taken into 625 account. 627 9. Security considerations 629 A detailed analysis of the security aspects related to the proposed 630 solution needs to be performed in order to check that no new 631 additional security issues will be introduced with respect to a SIP 632 solution that handles mobility using the traditional end-to-end based 633 approach. 635 10. Informative References 637 [niccolini-sip-HO] 638 S. Niccolini et al., "Requirements for vertical handover 639 of multimedia sessions using SIP", 640 draft-niccolini-sipping-siphandover-03 , May 2008. 642 [refs.rfc3261] 643 J. Rosenberg et al., "SIP: Session Initiation Protocol", 644 RFC 3261, June 2002. 646 [refs.rfc3911] 647 R. Mahy et al., "The Session Initiation Protocol (SIP) 648 "Join" Header", RFC 3911, October 2004. 650 [refs.rfc3891] 651 R. Mahy et al., "The Session Initiation Protocol (SIP) 652 "Replaces" Header", RFC 3891, September 2004. 654 [Salsano08] 655 S. Salsano et al., "SIP-based Mobility Management in Next 656 Generation Networks", IEEE Wireless Communication , 657 April 2008. 659 [Salsano07] 660 S. Salsano et al., "Architecture and testbed 661 implementation of vertical handovers based on SIP Session 662 Border Controllers", Wireless Personal Communications, 663 Springer , November 2007. 665 Appendix A. Acknowledgments 667 The authors would like to thank Chiara Mingardi (Univ. of Padova/NEC) 668 for her work on the implementation of the solution. 670 Authors' Addresses 672 Stefano Salsano 673 DIE, University of Rome "TorVergata" 674 Via Politecnico, 1 675 Rome 00133 676 Italy 678 Phone: +39 06 7259 7770 679 Email: stefano.salsano@uniroma2.it 680 URI: http://netgroup.uniroma2.it/Stefano_Salsano 682 Saverio Niccolini 683 Network Laboratories, NEC Europe Ltd. 684 Kurfuersten-Anlage 36 685 Heidelberg 69115 686 Germany 688 Phone: +49 (0) 6221 43 42 118 689 Email: saverio.niccolini@netlab.nec.de 690 URI: http://www.netlab.nec.de 692 Luca Veltri 693 DII, University of Parma 694 Parco Area delle Scienze 181/A 695 Parma 43100 696 Italy 698 Phone: +39 0521 90 5768 699 Email: luca.veltri@unipr.it 700 URI: http://www.tlc.unipr.it/veltri 702 Andrea Polidoro 703 DIE, University of Rome "TorVergata" 704 Via Politecnico, 1 705 Rome 00133 706 Italy 708 Phone: +39 06 7259 7773 709 Email: andrea.polidoro@uniroma2.it 710 URI: http://netgroup.uniroma2.it 712 Full Copyright Statement 714 Copyright (C) The IETF Trust (2008). 716 This document is subject to the rights, licenses and restrictions 717 contained in BCP 78, and except as set forth therein, the authors 718 retain all their rights. 720 This document and the information contained herein are provided on an 721 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 722 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 723 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 724 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 725 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 726 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 728 Intellectual Property 730 The IETF takes no position regarding the validity or scope of any 731 Intellectual Property Rights or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; nor does it represent that it has 735 made any independent effort to identify any such rights. Information 736 on the procedures with respect to rights in RFC documents can be 737 found in BCP 78 and BCP 79. 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 746 The IETF invites any interested party to bring to its attention any 747 copyrights, patents or patent applications, or other proprietary 748 rights that may cover technology that may be required to implement 749 this standard. Please address the information to the IETF at 750 ietf-ipr@ietf.org.