idnits 2.17.1 draft-yue-mmusic-rtsp-substream-control-extension-01.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 (March 2, 2012) is 4430 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) == Unused Reference: 'RFC4566' is defined on line 608, but no explicit reference was found in the text == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-27 == Outdated reference: A later version (-02) exists of draft-ietf-payload-rtp-mvc-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 mmusic P. Yue 2 Internet-Draft Huawei Technologies 3 Intended status: Standards Track March 2, 2012 4 Expires: September 3, 2012 6 RTSP Extension for Substream Control 7 draft-yue-mmusic-rtsp-substream-control-extension-01 9 Abstract 11 This document defines extensions to RTSP 2.0 protocol, including 12 header "SubstreamCtrl", feature tag "Play.substream" , and related 13 new status codes. These extensions enables the playback control of a 14 media stream on substream basis. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 3, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Definitions and Abbreviations . . . . . . . . . . . . . . 3 55 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Substream Annotation . . . . . . . . . . . . . . . . . . . 4 60 4.2. Capability Negotiation . . . . . . . . . . . . . . . . . . 5 61 4.3. Substream Playback Control . . . . . . . . . . . . . . . . 5 62 4.3.1. Substream Play/Resume . . . . . . . . . . . . . . . . . . 5 63 4.3.2. Substream Pause . . . . . . . . . . . . . . . . . . . . . 6 65 5. RTSP Extensions . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Play.substream Feature Tag . . . . . . . . . . . . . . . . 7 67 5.2. Substream Header . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Status Code Extension . . . . . . . . . . . . . . . . . . 7 69 5.3.1. 552 Substream Type Not Recognized . . . . . . . . . . . . 7 70 5.3.2. 553 Substream Control Not Allowed . . . . . . . . . . . . 8 71 5.3.3. 554 Substream Id Not Valid . . . . . . . . . . . . . . . . 8 73 6. SVC and MVC Substream Type . . . . . . . . . . . . . . . . 8 74 6.1. SVC Substream Type . . . . . . . . . . . . . . . . . . . . 8 75 6.2. MVC Substream Type . . . . . . . . . . . . . . . . . . . . 9 77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Security Considerations . . . . . . . . . . . . . . . . . 12 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 82 9.1. RTSP Feature-tag Extensions . . . . . . . . . . . . . . . 12 83 9.2. RTSP Header Extensions . . . . . . . . . . . . . . . . . . 13 84 9.3. RTSP Status Code Extension . . . . . . . . . . . . . . . . 13 85 9.4. Hold of Substream Type Registration . . . . . . . . . . . 13 86 9.4.1. Guidance of Substream Type Registration . . . . . . . . . 13 87 9.4.2. Registration of Substream Types . . . . . . . . . . . . . 13 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 93 Author's Address . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 Single Session Transmission (SST) is recommended for the SVC ( 98 Scalable Video Codec) video transport [RFC6190] and MVC (Multiview 99 Video Codec) video transport [I-D.ietf-payload-rtp-mvc] . In SST, a 100 single RTP session conveys all the related media data, namely all the 101 bitstream components. A bitstream component here is part of a media 102 stram that has a common property which could be: 103 o Layer: in SVC media stream; In this case, a bitstream component is 104 media data of a specific layer. 105 o View: in MVC media stream; In this case, a bitstream component is 106 media data of a specific view. 108 In such a SST session,one or several bitstream components together 109 may be decodable by themselves and therefore make sense to the 110 receiver. Here these bitstream component(s) combinations are here 111 Substream. 113 In SVC and MVC RTP sessions, such a Substream is identified by an 114 Operation Point. 116 There are cases that a client wants to retrieve a specific substream 117 in a SST session. However, in the current RTSP 2.0 protocol, the 118 control of the media is on basis of media stream i.e. an RTP session 119 when RTP is used as transport protocol. This prevents a client to 120 receive only certain substream(s) of the media. 122 This memo extends the RTSP 2.0[I-D.ietf-mmusic-rfc2326bis] to 123 establish a substream playback control framework, which enables a 124 client to play a part of a media stream. 126 This memo also defines the substream usage for SVC and MVC. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Definitions and Abbreviations 136 3.1. Definitions 138 The following terms are used in this document and have specific 139 meaning within the context of this document. 141 o Substream: a part of a media stream containing one or more 142 bitstream components, which can be independently decoded. 143 Typically a Substream is identified by a single operation point. 144 o Substream type: the compound mode of the bitstream components in a 145 media stream, e.g. SVC, MVC, etc 147 3.2. Abbreviations 149 SVC: Scalable Video Coding 150 MVC: Multiview Video Coding 151 SST: Single Session Transmission 153 4. Protocol Overview 155 The whole framework includes three parts: substream annotation, 156 capability negotiation and substream playback control. This section 157 provides an overview of substream control framework. 159 CLIENT SERVER 160 | | 161 | <------ substream annotation ------- | 162 | | 163 | | 164 | | 165 | <---- RTSP Session Setup(Capability Negotiation) ----> | 166 | | 167 | | 168 | <---- RTSP media playback control(play/pause) ----> | 169 | | 170 | | 171 Figure 1: Substream Control Framework Overview 173 4.1. Substream Annotation 175 Substream annotation is used to announce all substreams available in 176 a media stream, which can be retrieved selectively. This is done 177 through a presentation description, typically using SDP description. 179 Substream annotation SHALL signal the substream type and substream id 180 for each substream. 182 Substrean type is the compound mode of the bitstream components in a 183 media stream, e.g. SVC, MVC, etc. Here a media stream with SVC 184 substream type, means comforming to [RFC6190]. A media stream with 185 MVC substream type, means comforming to [I-D.ietf-payload-rtp-mvc]. 186 More specification of SVC and MVC substream type is defined at 187 Section 6. 189 Substream id is the identifier for a substream. The actual 190 definition of the substream id is defined by each substream type. 192 4.2. Capability Negotiation 194 Capability negotiation is used to negotiate support of substream 195 control between RTSP client and server. It makes use of the RTSP 196 feature tag mechanism defined in RTSP 197 2.0[I-D.ietf-mmusic-rfc2326bis]. A new feature tag (play.substream) 198 is defined in Section 5.1 of this document. 200 If received a media presentation with substream annotation, a 201 substream control capable RTSP client SHALL include play.substream in 202 the REQUIRE header of the RTSP SETUP request. This indicates that 203 the client is able to control the playback of the media on substream 204 basis. 206 A 2xx response implies that the server is capable of substream 207 control. A server MAY refuse the request with a 551 "Option not 208 supported" response, with an UNSUPPORT header including 209 play.substream. 211 The receiving client may try to setup a session without this feature 212 later. This means that the client will not perform substream control 213 and will retrieve the media as a whole. 215 4.3. Substream Playback Control 217 In case the session is setup correctly, the client may control the 218 play back on substream basis, including: 219 o start to play/resume a substream 220 o pause a substream. Note that this means pause the play back of 221 the whole session. 223 4.3.1. Substream Play/Resume 225 After successful set up of an RTSP session, the client may perform 226 substream playback control. The playback of a substream is similar 227 with the normal playback of a session, except that the PLAY request 228 SHALL contain a "SubstreamCtrl" header to signal the substream(s) 229 that the client intends to play. 231 The SubstreamCtrl header, as defined in Section 5.2, SHALL contain at 232 least the substream type and the substream id of each substream. In 233 the case of aggregate control, the header SHALL further contain 234 Request-URIs for each of the the substreams. 236 A client SHOULD NOT perform substream play if the server has not 237 indicated support of substream control during session setup. 239 Upon receiving a PLAY request with a "SubstreamCtrl" header, the 240 server SHALL identify the substream(s) according to the substream 241 type. substream id and optional Request-URI combination(s) in the 242 request, and then provides the indicated substream(s) after sending a 243 200 OK response. 245 If the server doesn't support substream control, it SHALL respond 246 with a 551 "Option not supported" response as defined in RTSP 247 2.0[I-D.ietf-mmusic-rfc2326bis]. 249 If the server supports substream control but the substream type 250 indicated in the "SubstreamCtrl" header is not recognized, it SHALL 251 respond with a 552 "Substream Type Not Recognizable" response, see 252 Section 5.3.1. 254 If a requested media is not allowed to be played on substream basis 255 as requested, the server SHALL respond with a 553 "Substream Control 256 Not Allowed" response, see Section 5.3.2. 258 If the requested substream id is not valid, the server SHALL respond 259 with a 554 "Substream id not valid", see Section 5.3.3. 261 4.3.2. Substream Pause 263 The pause operation of a substream is identical to the pause 264 operation of a normal RTSP session. It is not necessary for the 265 client to include a "SubstreamCtrl" header in the PAUSE request 266 message. However, if the request includes a "SubstreamCtrl" header, 267 it SHALL list all the substreams are currently played. 269 Upon receiving a PAUSE request without a SubstreamCtrl header, the 270 server SHALL pause the stream(s) according to RTSP 271 2.0[I-D.ietf-mmusic-rfc2326bis]. 273 Upon receiving a PAUSE request with a SubstreamCtrl header, the 274 server SHALL check the substream list contained. If the substream 275 list is not identical to the ones that is in the play status, the 276 server SHALL respond with a 553 "Substream Control Not Allowed" 277 response, see Section 5.3.2. Otherwise, the server SHALL respond 278 with 2xx message and pause the stream(s) properly. 280 5. RTSP Extensions 282 This section documents the extension to the RTSP 2.0 specification. 284 Specifically Section 5.2 specifies the SubstreamCtrl header, 285 Section 5.1 specifies the substream control feature tag, Section 5.3 286 specifies the status codes extentions for the substream control 287 feature. 289 5.1. Play.substream Feature Tag 291 The following feature-tag is defined in this specification and hereby 292 registered. The change control belongs to the IETF. 294 play.substream: Support of substream control operations for media 295 playback. Applies for both clients and servers. 297 Notes that this feature is based the play.basic therefore spport of 298 this feature inheritly means support of play.basic. 300 5.2. Substream Header 302 SubstreamCtrl header is used to indicate the substream(s) of media 303 stream(s) that the client intends to play. 305 SubstreamCtrl header can be used in PLAY and PAUSE request. Proxies 306 shall not modify this header and pass through to the server. 308 SubstreamCtrl header contains one or more [stream uri, substream 309 type, substream id] triple. The syntax is: 311 SubstreamCtrl = "SubstreamCtrl:" 312 substream-id * (";" sustream-id) 313 substream-id = [stream-uri ","] 314 substream-type "," substream_id 315 stream-uri = RTSP-URI 316 substream-type= "SVC" / "MVC" / token 318 5.3. Status Code Extension 320 This clause defines the status codes extended for the substream 321 control feature. They are: 322 o 552 Substream Type Not Recognized 323 o 553 Substream Control Not Allowed 324 o 554 Substream Id Not Valid 326 5.3.1. 552 Substream Type Not Recognized 328 The server can not recognize one or more substream type(s) in the 329 SubstreamCtrl header of the request. 331 5.3.2. 553 Substream Control Not Allowed 333 One or more media streams identified by the Request-URI in the 334 request is not allowed for the substream control. 336 5.3.3. 554 Substream Id Not Valid 338 One or more substream id(s) specified in the request are not valid 339 for the media identified by the Request-URI. 341 6. SVC and MVC Substream Type 343 6.1. SVC Substream Type 345 This section provides the specification of substream type for SVC 346 Stream: Substream Type: "SVC" Substream annotation: 348 In SVC, a substream is identical to an operation point, which 349 consists of the bitstream components required to be decoded 350 independently. 352 Operation points are signalled in SDP, by ether of the following two 353 parameters : 354 o sprop-operation-point-info: According to [RFC6190], this parameter 355 consists of a comma-separated list of operation-point-description 356 vectors, including ayer-ID, dependency-ID, temporal_ID, 357 quality-ID. Among them, the value of layer-ID specifies the layer 358 identifier of the operation point, which is identical to the 359 layer_id that would be indicated (for the same values of 360 dependency_id, quality_id, and temporal_id) in the scalability 361 information SEI message. 362 o sprop-scalability-info: According to [RFC6190], This parameter is 363 used to convey the NAL unit containing the scalability information 364 SEI message as specified in Annex G of [H.264]. Within the 365 scalability information SEI message, layer information of the SVC 366 stream is signalled, including layer_id, dependency_id, 367 quality_id, and temporal_id. 369 Therefore, substreams in a SVC stream is identified by either 370 layer-ID or a [dependency-ID, temporal_ID, quality-ID] combination. 372 The syntax of substream_id is: 374 substream_id = layer-id 375 /(dependency-id ","temporal-id "," quality-id) 376 layer-id = "layer_id=" layer_id_value 377 layer_id_value = 1*4DIGIT ;0~2047 378 dependency-id = "dependency_id=" dependency_id_value 379 dependency_id_value = DIGIT ;0~7 380 temporal-id = "temporal_id=" temporal_id_value 381 temporal_id_value = DIGIT ;0~7 382 quality-id = "quality_id=" quality_id_value 383 quality_id_value = 1*2DIGIT ;0~15 384 DIGIT = %x30-39 ;any US-ASCII digit "0".."9" 386 An example of Substream header is: 388 SubstreamCtrl: rtsp://example.com/svc.mp4, SVC, lay-id=1 390 6.2. MVC Substream Type 392 This section provides the specification of substream type for SVC 393 Stream: Substream Type: "SVC" Substream annotation: Annocation of MVC 394 substreams is specified in [I-D.ietf-payload-rtp-mvc]. 396 editor notes: pending on the complement of 397 [I-D.ietf-payload-rtp-mvc]. 399 Substream_id: 401 For the MVC case, the syntax of substream_id is: 403 editor's notes: pending on the complement of mvc-operation-point-id 405 7. Examples 407 The following takes substream control of a SVC stream as an example. 408 Step 1: Client C requests a presentation from media server S. The 409 media is a video encoded by SVC and transported by SST. 411 C->S: DESCRIBE rtsp://example.com/BreakingDawn.3gp RTSP/2.0 412 CSeq: 1 413 User-Agent: PhonyClient/1.2 415 S->C: RTSP/2.0 200 OK 416 CSeq: 1 417 Server: PhonyServer/1.0 418 Date: Wed, 22 Feb 2012 15:20:29 GMT 419 Content-Type: application/sdp 420 Content-Length: 407 421 Content-Base: rtsp://example.com/BreakingDawn.3gp/ 422 Expires: 22 Feb 2012 15:20:29 GMT 424 v=0 425 o=- 2890844256 2890842807 IN IP4 198.51.100.5 426 s=RTSP Session 427 i=An Example of substream control usage 428 e=adm@example.com 429 c=IN IP4 0.0.0.0 430 a=control: * 431 a=range: npt=0-0:10:34.10 432 t=0 0 433 m=video 20000 RTP/AVP 97 434 a=rtpmap:97 H264-SVC/90000 435 a=fmtp:97 profile-level-id=53000c; packetization-mode=1; 436 sprop-parameter-sets={sps0},{sps1},{pps0},{pps1}; 437 sprop-operation-point-info=<1,0,0,0,4de00a,3200,176,144,128, 438 256>,<2,1,1,0,53000c,6400,352,288,256,512>; 440 Step 2: The client setup the RTSP session with play.substream feature 441 tag. 443 C->S: SETUP rtsp://example.com/BreakingDawn.3gp RTSP/2.0 444 CSeq: 2 445 User-Agent: PhonyClient/1.2 446 Require: play.substream 447 Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" 448 Accept-Ranges: NPT, SMPTE, UTC 450 S->C: RTSP/2.0 200 OK 451 CSeq: 3 452 Server: PhonyServer/1.0 453 Transport: RTP/AVP;unicast; ssrc=AABBCCDD; 454 dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; 455 src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; 457 Session: 12345678 458 Expires: 22 Feb 2012 15:22:09 GMT 459 Date: 22 Feb 2012 15:22:09 GMT 460 Accept-Range: NPT 461 Media-Properties: Random-Access=0.8, Immutable, Unlimited 463 Step 3: The client starts the playout of the component layer 1. 465 C->S: PLAY rtsp://example.com/BreakingDawn.3gp/ RTSP/2.0 466 CSeq: 4 467 User-Agent: PhonyClient/1.2 468 Range: npt=0- 469 Seek-Style: RAP 470 Session: 12345678 471 SubstreamCtrl: SVC, layer_id=1 473 S->C: RTSP/2.0 200 OK 474 CSeq: 4 475 Server: PhonyServer/1.0 476 Date: 22 Feb 2012 15:22:52 GMT 477 Session: 12345678 478 Range: npt=0-634.10 479 Seek-Style: RAP 480 RTP-Info: url="rtsp://example.com/BreakingDawn.3gp" 481 ssrc=0D12F123:seq=12345;rtptime=3450012, 483 Step 4: The client requests to pause the session. 485 C->S: PAUSE rtsp://example.com/BreakingDawn.3gp/ RTSP/2.0 486 CSeq: 5 487 User-Agent: PhonyClient/1.2 488 Session: 12345678 489 SubstreamCtrl: SVC, layer_id=1 491 S->C: RTSP/2.0 200 OK 492 CSeq: 5 493 Server: PhonyServer/1.0 494 Date: 22 Feb 2012 15:22:58 GMT 495 Session: 12345678 496 Range: npt=5.66-634.10 498 8. Security Considerations 500 Considerations outlined in RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] 501 apply here as well. It is believed that no special security risk is 502 led by this document. 504 9. IANA Considerations 506 Registration is requested for the newly defined RTSP feature tag 507 extension, RTSP header extensions and RTSP status code extensions, 508 according to the instructions in section 22 of the base specification 509 [I-D.ietf-mmusic-rfc2326bis]. 511 This section also sets up a registry for substream type that should 512 be maintained by IANA. 514 9.1. RTSP Feature-tag Extensions 516 The following feature-tag is defined in this specification and hereby 517 registered according to the section 22.1.2 of the base specification 518 [I-D.ietf-mmusic-rfc2326bis]. The change control belongs to the 519 IETF. 521 o Feature tag: Play.substream 522 o Description: Support of control the media playback on substream 523 basis. Applies for clients, servers and proxies. 524 o Contact person: Peiyu YUE 525 o Change control: IETF 526 o Reference specification: present document. 528 9.2. RTSP Header Extensions 530 The following RTSP header is defined in this specification and hereby 531 registered according to section 22.4.2 of the base specification 532 [I-D.ietf-mmusic-rfc2326bis]. The change control belongs to the 533 IETF. 535 o The name of the header: SubstreamCtrl 536 o Description: SubstreamCtrl is used to indicate the substreams RTSP 537 client wants to control(i.e. play or pause). 538 o The syntax of the header: as described in Section 5.2. 539 o Where to use: as described in Section 5.2. 540 o Handle by proxy: default. 542 9.3. RTSP Status Code Extension 544 The following RTSP status codes are in defined this specification and 545 hereby registered according to section 22.3.2 of the base 546 specification [I-D.ietf-mmusic-rfc2326bis]. The change control 547 belongs to the IETF. 549 o Request number: 552 550 o Description: as described in Section 5.3.1 552 o Request number: 553 553 o Description: as described in Section 5.3.2 555 o Request number: 554 556 o Description: as described in Section 5.3.3 558 9.4. Hold of Substream Type Registration 560 9.4.1. Guidance of Substream Type Registration 562 IANA should take the responsibility for the registration of the 563 substream type. A new substream type MUST be registered through an 564 IETF Standards Action. A specification for a new substream type MUST 565 consist of the following items: 566 o A substream type; 567 o A description of the substream type; 568 o A substream id definition 570 9.4.2. Registration of Substream Types 572 This specification registers two substream types: SVC and MVC: 574 o Substream Type: SVC 575 o Description: Scalable Video Codec stream as defined in [RFC6190]. 576 o Substream id definition: could be layer-id or [dependency-ID, 577 temporal_ID, quality-ID] combination, as described in Section 4.1. 579 o Substream Type: MVC 580 o Description: Multiview Video Codec stream as defined in 581 [I-D.ietf-payload-rtp-mvc]. 582 o Substream id definition: as described in Section 4.1. 584 10. References 586 10.1. Normative References 588 [I-D.ietf-mmusic-rfc2326bis] 589 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 590 and M. Stiemerling, "Real Time Streaming Protocol 2.0 591 (RTSP)", draft-ietf-mmusic-rfc2326bis-27 (work in 592 progress), March 2011. 594 [I-D.ietf-payload-rtp-mvc] 595 Wang, Y. and T. Schierl, "RTP Payload Format for MVC 596 Video", draft-ietf-payload-rtp-mvc-00 (work in progress), 597 March 2011. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 603 "RTP Payload Format for Scalable Video Coding", RFC 6190, 604 May 2011. 606 10.2. Informative References 608 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 609 Description Protocol", RFC 4566, July 2006. 611 Author's Address 613 Peiyu Yue 614 Huawei Technologies 615 Huawei Base 616 101 Software Avenue, Yuhua District 617 Nanjing, Jiangsu 210012 618 China 620 Phone: +86-25-56620258 621 Email: yuepeiyu@huawei.com