idnits 2.17.1 draft-songyue-dispatch-invite-usage-indication-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Aug 2012) is 4262 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group Y. Song 3 Internet-Draft Y. Jiang 4 Intended status: Standards Track China Mobile 5 Expires: February 2, 2013 Aug 2012 7 Private Header (P-Header) Extensions to the Session Initiation Protocol 8 (SIP) for support of Indication of Dialog Type 9 draft-songyue-dispatch-invite-usage-indication-00 11 Abstract 13 This document describes private extensions to the Session Initiation 14 Protocol (SIP) that enable a SIP entity to indicate in the INVITE 15 message the exact purpose of the INVITE transaction, e.g. media 16 negotiation, session refresh or creation of an pure signaling dialog. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 2, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. P-INVITE-Type Header Field definition . . . . . . . . . . . . 5 55 4. UA behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.1. Creating a normal session with media negotiation . . . . . 7 58 5.2. Creating a pure signaling session . . . . . . . . . . . . 8 59 5.3. Doing session refresh . . . . . . . . . . . . . . . . . . 9 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 63 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 The Session Initiation Protocol (SIP) provides capability to create a 69 dialog using INVITE transaction. When creating dialog with INVITE, 70 there always media negotiation accompanied. When the UAC includes an 71 SDP offer in the INVITE message, the UAS will also includes SDP 72 answer in the response message. If there is no body in the INVITE 73 message, the UAS will include SDP offer in the response message, for 74 example 200 OK, then the UAC must send SDP answer in the ACK message, 75 so the media negotiation is done. 77 In some scenarios the using of INVITE transaction is only to create a 78 pure signaling session, no media is needed. Example could be the 79 media server control using MSML. The controller uses INVITE to 80 create a control dialog with the media server, and then send INFO 81 messages that carrying MSML body within the dialog. The second 82 example is within the Third Generation Partnership Project (3GPP) IP 83 Multimedia Subsystem (IMS). When Unstructured Supplementary Service 84 Data (USSD) service is provided in IMS, a dialog is created between 85 UE and the network, then the USSD data is transmit using INFOs within 86 the dialog. In such scenarios, the media negotiation is unnecessary 87 and it may make overhead to reserve media resource. Third example is 88 for the session refresh, in which the refresher sends INVITE only to 89 refresh the session timer, media re-negotiation is unnecessary. 91 This document attempts to provide a mechanism that enables the SIP 92 entity to indicate in the INVITE message the exact purpose of the 93 INVITE transaction. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. P-INVITE-Type Header Field definition 103 The P-INVITE-Type header field conveys the usage of the INVITE 104 message. It is place only in INVITE requests. 106 The syntax of the P-INVITE-Type header field is as follow: 108 P-INVITE-Type = "P-INVITE-Type" HCOLON invite-type 109 Invite-type = "media-negotiation"/"ini-sig-dialog"/ 110 "refresh-session" 112 The P-INVITE-Type value "media-negotiation" indicates that the INVITE 113 request is to create a normal session with media negotiation, which 114 is the current usage of INVITE request. The value "ini-sig-session" 115 indicates that the current INVITE request is to create a pure 116 signaling dialog, no media negotiation is needed. The value 117 "refresh-session" indicates that the INVITE request is used to 118 refresh an existing session. 120 4. UA behavior 122 When UAC is sending an INVITE request, it SHOULD insert a P-INVITE- 123 Type header into the message and set the value according to the 124 purpose of this INVITE request. If the value is set to "ini-sig- 125 session" or "refresh-session", the UAC MUST NOT include SDP body in 126 the INVITE request. If the UAC is to create a normal session with 127 media negotiation, it may not insert the P-INVITE-Type header field. 129 When UAS receive an INVITE request with a P-INVITE-Type header field, 130 it must check the value of this header. If the value is "ini-sig- 131 session" or "refresh-session" the UAS will know that this INVITE 132 transaction does not do media negotiation and MUST NOT include any 133 SDP body in the corresponding response messages. If the INVITE 134 request does not contain P-INVITE-Type header field, the UAS MUST 135 treat it as the P-INIVTE-Type value is "media-negotiation". 137 5. Examples 139 5.1. Creating a normal session with media negotiation 141 Alice Bob 142 |(1) INVITE | 143 |P-INVITE-Type: | 144 |media-negotiation | 145 |----------------->| 146 |(2) 200 OK | 147 |<-----------------| 148 |(3) ACK | 149 |----------------->| 150 | | 151 |------------------| 152 | media setup | 153 |------------------| 155 Figure 1: Example of creating normal session 157 Figure 1 gives an example of a normal use of INVITE request. In this 158 example, UAC includes a P-INVITE-Type header field in the INVITE 159 message and the value is set to "media-negotiation". The INVITE 160 request generated by UAC (message 1) might look like this: 162 INVITE sip:bob@example.com SIP/2.0 163 Via: SIP/2.0/UDP alice.example.com;branch=z9hG4bKnashds8 164 Max-Forwards: 70 165 To: Bob 166 From: Alice ;tag=1928301774 167 Call-ID: a84b4c76e66710 168 CSeq: 1 INVITE 169 Contact: 170 P-INVITE-Type: media-negotiation 171 Content-Type: application/sdp 172 Content-Length: 200 173 (Alice's SDP not shown) 175 This request indicates that Alice wants to create a normal session 176 with Bob and the SDP body is included in the message. 178 When Bob receive this message, deals with the SDP offer in the 179 request then send SDP answer in the 200 OK response. 181 5.2. Creating a pure signaling session 183 Alice Bob 184 |(1) INVITE | 185 |P-INVITE-Type: | 186 |ini-sig-session | 187 |----------------->| 188 |(2) 200 OK | 189 |<-----------------| 190 |(3) ACK | 191 |----------------->| 192 | | 193 |------------------| 194 | no media setup | 195 |------------------| 196 | | 197 |(4) INFO | 198 |----------------->| 199 |(5) 200 OK | 200 |<-----------------| 201 |(6) IFNO | 202 |<-----------------| 203 |(7) 200 OK | 204 |----------------->| 205 |(8) BYE | 206 |----------------->| 207 |(9) 200 OK | 208 |<-----------------| 210 Figure 2: Example of creating pure signaling session 212 Figure 2 shows how to use INVITE request to create a pure signaling 213 session. In this example, a signaling dialog is first created 214 between Alice and Bob, then they exchange data using INFO request 215 within the dialog. Alice inserts P-INVITE-Type into the INVITE 216 message and sets the value to "ini-sig-dialog". The INVITE message 217 sent by Alice (message 1) has no body and may look like this: 219 INVITE sip:bob@example.com SIP/2.0 220 Via: SIP/2.0/UDP alice.example.com;branch=z9hG4bKnashds8 221 Max-Forwards: 70 222 To: Bob 223 From: Alice ;tag=1928301774 224 Call-ID: a84b4c76e66710 225 CSeq: 1 INVITE 226 Contact: 227 P-INVITE-Type: ini-sig-dialog 228 Content-Length: 0 230 Bob receives the INVITE request and finds that the P-INIVTE-Type 231 header is set to "ini-sig-dialog", then it will not include any 232 message body in the response message. 234 The INFO requests sent between Alice and Bob use the same Call-ID as 235 the previous INVITE request, like this: 237 INFO sip:bob@example.com SIP/2.0 238 Via: SIP/2.0/UDP alice.example.com;branch=z9hG4bKnashDFSD2 239 Max-Forwards: 70 240 To: Bob 241 From: Alice ;tag=1928301774 242 Call-ID: a84b4c76e66710 243 CSeq: 2 INFO 244 Contact: 245 Content-Type: -- content-type -- 246 Content-Length: -- content-length-- 247 -- Content in the INFO request -- 249 5.3. Doing session refresh 251 Alice Bob 252 | | 253 |------------------| 254 | session exsiting | 255 |------------------| 256 | | 257 |(1) INVITE | 258 |P-INVITE-Type: | 259 |refresh-session | 260 |----------------->| 261 |(2) 200 OK | 262 |<-----------------| 263 |(3) ACK | 264 |----------------->| 266 Figure 3: Example of session refreshing 268 Figure 3 gives an example of session refreshing. A session has been 269 created between Alice and Bob, and session timer is required. When 270 Alice sends INVITE request for session refreshing, it inserts a 271 P-INVITE-Type header into the message and sets the value to "refresh- 272 session", no message body is included in the request. Message 1 may 273 look like this: 275 INVITE sip:bob@example.com SIP/2.0 276 Via: SIP/2.0/UDP alice.example.com;branch=z9hG4bKnashds8 277 Max-Forwards: 70 278 To: Bob 279 From: Alice ;tag=1928301774 280 Call-ID: a84b4c76e66710 281 CSeq: 3 INVITE 282 Contact: 283 P-INVITE-Type: refresh-session 284 Content-Length: 0 286 6. Security Considerations 287 7. IANA Considerations 288 8. Acknowledgements 289 9. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 Authors' Addresses 296 Yue Song 297 China Mobile 298 32 Xuanwumenxi Ave, 299 Xuanwu District 300 Beijing 100053 301 P.R.China 303 Email: songyue@chinamobile.com 305 Yi Jiang 306 China Mobile 307 32 Xuanwumenxi Ave, 308 Xuanwu District 309 Beijing 100053 310 P.R.China 312 Email: jiangyi@chinamobile.com