idnits 2.17.00 (12 Aug 2021) /tmp/idnits46044/draft-mou-pcp-application-network-feedback-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6887]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 10, 2014) is 2742 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) == Outdated reference: draft-ietf-pcp-server-selection has been published as RFC 7488 == Outdated reference: draft-ietf-httpbis-http2 has been published as RFC 7540 == Outdated reference: draft-ietf-pcp-authentication has been published as RFC 7652 == Outdated reference: draft-ietf-pcp-proxy has been published as RFC 7648 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-08) exists of draft-liu-sfc-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group H. Moustafa 3 Internet-Draft D. Moses 4 Intended status: Standards Track Intel Corporation 5 Expires: May 14, 2015 M. Boucadair 6 France Telecom 7 November 10, 2014 9 PCP Extension for Signaling Feedback Information from the End-User 10 Application to the Application Sever and to the Network 11 draft-mou-pcp-application-network-feedback-02 13 Abstract 15 Nowadays users consumption style for video and multimedia 16 applications is strongly changing. Users are consuming content 17 through multi-screen and are heavily counting on wireless and mobile 18 devices for video streaming and interactive video and multimedia 19 applications. This necessitates more intelligence in the service and 20 the network infrastructure to better suit a differentiated users 21 consumption style, which can be achieved through having: (i) a 22 knowledge in the network and service platform about the available 23 device and network conditions for the end-user and (ii) a knowledge 24 in the network about the content requirements in terms of devices 25 capabilities and network resources for content stored either in the 26 network or in the application server. To obtain such knowledge with 27 no need for changing the current infrastructure and in a generalized 28 way to all applications, feedback/notification mechanisms between the 29 end-user application, the network and the service platform is needed 30 to provide information helping the content delivery and adaptation 31 decisions. This document is investigating such application-agnostic 32 track. 34 This document extends the Port Control Protocol (PCP) RFC 6887 35 [RFC6887] to allow: (i) the users application to notify the network 36 and application server about its available resources in terms of 37 devices capabilities and network conditions as well as information 38 about the user (e.g., location, mobility status) and (ii) the 39 application server to notify the network about the requirements of 40 the content it stores in terms of devices and network resources. A 41 new PCP option, denoted the FEEDBACK, is specified to allow such 42 feedback notification signaling. This option is used with both PEER 43 and MAP Opcodes. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on May 14, 2015. 62 Copyright Notice 64 Copyright (c) 2014 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 81 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3.1. Real-time Transcoding for Video Delivery Optimization . . 4 83 3.2. Content Adaptation during Content Mirroring to External 84 Display . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 3.3. Optimization Examples . . . . . . . . . . . . . . . . . . 5 86 4. Why PCP? . . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 5. FEEDBACK PCP Option . . . . . . . . . . . . . . . . . . . . . 7 88 5.1. PCP Request and Responses . . . . . . . . . . . . . . . . 8 89 6. Security Consideration . . . . . . . . . . . . . . . . . . . 10 90 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 10 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 9.2. Informative References . . . . . . . . . . . . . . . . . 11 95 Appendix A. Existing Protocols of Relevance to User's Feedback 96 Information and their Limitations . . . . . . . . . 13 98 1. Introduction 100 Nowadays, Internet traffic includes huge amount of video traffic 101 which is expected to highly dominate the Internet traffic in the 102 coming years. The users consumption style for video services is 103 strongly evolving towards a user-centric model enabling video 104 services access based on users profiles and making receiving device 105 (e.g., Laptops, tablets, smartphones, and future devices models) 106 constitute the majority of end-user devices for video services 107 through plenty of services over the Internet. 109 Although this big evolution, the network and service infrastructure 110 are not optimized enough to handle the content delivery and 111 adaptation function of the network resources, devices resources, 112 application and content requirements. As a result, Quality of 113 Experience (QoE) for video services and multimedia applications can 114 not be guaranteed in some situations. 116 This document defines an extension to the Port Control Protocol (PCP) 117 RFC 6887 [RFC6887] allowing: (i) the end-user application to signal 118 in real-time to the network and application server information about 119 its available device capabilities and network connectivities (e.g., 120 support to different content bitrates, buffering status as an 121 indication of the network connectivity level) as well as other useful 122 context information (e.g., location, mobility status) and (ii) the 123 application server to signal in real-time to the network the 124 requirement of the content it stores in terms of devices and network 125 resources. The extension defines a new PCP option for the existing 126 PEER and MAP OpCodes: FEEDBACK Option for signaling information 127 between the end-users application, the network and the application 128 server. 130 Motivations to undertake this effort are discussed in Section 3 131 through a number of use cases, while justifications for the use of 132 PCP are elaborated in Section 4. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 3. Use Cases 142 The new model for video services consumption over mobile and wireless 143 networks creates the need for feedback information between the end- 144 user application, the network and the service platform in real-time. 145 This helps optimizing the content for device/network resources on one 146 hand and end-user QoE and battery experience on the other hand. In 147 this view more intelligence needs to be considered in the network. A 148 way to do that is through having several service functions in the 149 network middle boxes on the path between the end-user and the 150 application server, as shown in Draft [ServiceFunctions], that could 151 be collocated with the NAT function or not. Examples of service 152 functions that we consider to better manage the video delivery are: 153 video optimization function (including transcoding), caching 154 capabilities, TCP optimizer, video controller allowing for example 155 content recommendation or intelligent scheduling in the case of 156 cellular networks. The following subsections present a use-case on 157 video delivery optimization using PCP signaling to provide feedback 158 information between the end-user application, the network and the 159 service platform: 161 3.1. Real-time Transcoding for Video Delivery Optimization 163 In this use-case, the end-users device is the host implementing the 164 PCP client and a middle box network node in the network (e.g. edge 165 router, home gateway or any cache node close to the user) is the PCP 166 server. This middle box node can store a copy of the content or can 167 be just a content relay from the application server to the end-user. 169 o If the middle box network node is only a relay, then it receives 170 the feedback information sent to the network by the end-user 171 application and by the application server and makes use of this 172 information for optimizing the content it relays to the end-user 173 through real-time transcoding. This allows the server to send one 174 version of content to the network node and this latter does real 175 time transcoding to several clients with different capabilities 176 connected to the edge router. The middle box network node can be 177 an edge router or home gateway supporting real-time transcoding 178 function. 180 o If the middle box network node stores a copy of the content, then 181 it makes use of the feedback information sent to the network by 182 the end-user application to optimize the stored content when 183 requested by the end-user before its delivery. This allows 184 optimizing the storage space through storing few presentations of 185 content and providing the necessary presentation on-demand through 186 real-time transcoding. The middle box network node can be a 187 network cache node, edge router or home gateway caching the 188 content and supporting real-time transcoding function. 190 3.2. Content Adaptation during Content Mirroring to External Display 192 In this use-case, the end-users device implements the PCP server and 193 the external display adaptor implements the PCP client. The former 194 can be a PC, tablet or Smartphone and the latter is the TV adaptor/ 195 box receiving the content from the end-user device. The end user- 196 device mirrors the content to the TV screen through wireless WiDi, 197 Miracast, or Airplay. 199 o The TV adaptor (e.g. WiDi or Miracast receivers) makes use of the 200 feedback information to share the TV screen characteristics and 201 the wireless connectivity status. The end-user device uses this 202 information to optimize the mirrored content function of the TV 203 characteristics (e.g. screen resolution, frames per second, screen 204 refresh rate). 206 3.3. Optimization Examples 208 The following are some examples on how to optimize the content for 209 device and network resources on one hand and end-user QoE and battery 210 experience on the other hand. 212 o For a high display resolution, a video of high bitrate/resolution 213 is sent if the users application buffering level and the global 214 network bandwidth conditions are sufficient and the battery level 215 is sufficient. 216 o If the battery level degrades during the session even if the users 217 application buffering level remains sufficient, then the video is 218 continued to be streamed in lesser bitrate/resolution to save 219 battery and prevent video session interruption due to battery 220 failure (keeping a threshold on the quality based on the remaining 221 resources). In this case, lesser resources can be allocated for 222 cellular users to match the bandwidth required for the low bitrate 223 video. 224 o If the battery level is fine but the users application buffering 225 level and global network bandwidth conditions degrades, the video 226 switches to lower bitrate (following the ordinary adaptive 227 streaming approach), which in turns save in the battery level. 228 o For small size display, the transmission errors are less observed 229 by the user especially if the user is mobile and is in a noisy 230 environment and so video can be displayed with lesser quality 231 (bitrate) to save battery resources and network resources even if 232 the buffering level and global network bandwidth conditions are 233 not poor. This is much useful for content categories as news and 234 non-live content, in which transmission errors have lesser impact 235 on the users perception. 237 4. Why PCP? 239 The use of PCP to signal feedback/notification between the end-users 240 application, the network and service platform in real-time is 241 motivated by the following: In the Port Control Protocol (PCP) 242 specification RFC 6887 [RFC6887], PCP is viewed as a request/response 243 protocol and also as a hint/notification protocol between a PCP 244 client and a PCP server. Message flows in PCP are viewed as 245 independent streams carrying information between the PCP client and 246 the PCP server, in which the PCP client sends a stream of hints 247 indicating to its server its mapping status and the PCP server sends 248 to the client a notification informing the client on the actual state 249 of its mapping. In this view of the protocol, PCP can be extended to 250 carry more mapping information than the IP internal versus external 251 addresses. Draft [Flowdata] is an example of the use of PCP for 252 signaling by the client the flow characteristics to the network and 253 signaling by the network its ability to accommodate that flow back to 254 the client. 256 In addition, PCP allows learning and influencing the mapping 257 lifetime, which helps reducing network bandwidth, overload on 258 application servers and middle boxes and battery resources for 259 wireless and mobile devices. This makes PCP suitable for conveying 260 feedback information in our use-cases in real-time and resource wise 261 way. 263 Further advantages for PCP motivating its use are as follows: 265 o PCP can be used to install state in upstream devices such as NAT, 266 firewalls or other flow-aware devices. 267 o PCP can be used to notify a failure that may occur at an upstream 268 PCP-controlled device, and therefore the PCP client can react 269 accordingly. 270 o PCP allows learning the lifetime of installed mappings and would 271 therefore avoid overloading the network and service platform with 272 keepalive messages. This also saves the battery resources for 273 wireless and mobile end-user devices. 274 o PCP can be used to notify the network with the flow 275 characteristics so as to enforce policies at the access segment. 276 o PCP can be used to receive informative information from the 277 network so that client may use them to select the interface to use 278 to place a session. 279 o PCP can be extended easily to allow reporting capabilities to a 280 remote server. 282 o Extending PCP with the FEEDBACK feature avoids making assumptions 283 on how media streams are exchanged (e.g., RTP, IAX mini-frames, 284 etc.). 285 o PCP extension does not require an OS support. The feature can be 286 managed at the application level. 288 5. FEEDBACK PCP Option 290 This document presents an extension to PCP through the definition of 291 FEEDBACK option in PCP. The FEEDBACK option aims to signal feedback 292 information between the end-user application, the network and service 293 platform to help optimizing the network and devices resources and 294 enhancing the users experience. This feedback mechanism makes also 295 use of the PCP FLOWDATA option [Flowdata]. This means that the PCP 296 client sends both FLOWDATA and the FEEDBACK options in the same 297 requests. 299 The information signaled in the FEEDBACK Option may include the 300 screen size, screen resolution and battery level as device 301 capabilities information and the users location, environment type and 302 mobility status as context information on the user side. This 303 information is signaled once at the beginning of the session and can 304 be updated upon variation. Following the information signaling, the 305 PCP server uses the FEEDBACK option to signal its ability of 306 providing content with characteristics matching the device and 307 network resources as well as the user context. This information will 308 be used by the application server and by the network (through the 309 middle box network nodes having service functions) for optimized 310 content adaptation as explained in Section 3. 312 The FEEDBACK option does not make any assumption on the presence of 313 NAT and/or firewall. In particular, PCP-based mechanism to 314 instantiate state in an upstream NAT, firewall and any other flow- 315 aware device are not impacted by the use of FEEDBACK option. 317 The PCP client is implemented at the end-user device and the 318 application server (content server), and the PCP server is 319 implemented at the middle box network node storing the content and 320 the application server. The PCP client may be configured with 321 multiple IP addresses; each of them pointing to a distinct PCP 322 server. The PCP client will contact all these PCP server in parallel 323 as discussed in [I-D.ietf-pcp-server-selection]. 325 A PCP Proxy [PCPProxy] functionality can be enabled in intermediate 326 nodes (e.g., Customer Premise Equipment (CPE)) on the path between 327 the PCP client and the PCP server. 329 Upon receipt of the FEEDBACK option by the PCP Server, its content is 330 passed to the Application Server that decides whether an action is 331 needed to serve the requesting client to better accommodate its 332 resources and conditions. 334 The procedure for generating a request that includes the FEEDBACK 335 option, handling a request that includes the FEEDBACK option, and 336 generating a response to a request that includes the FEEDBACK option 337 is similar to the behavior specified in [Flowdata]. 339 Triggers to generate a request that capture the network conditions 340 and device recourses in a FLOWDATA and FEEDBACK options are local to 341 the application. How the application server or network middle boxes 342 makes use of the content of the FLOWDATA and FEEDBACK options is also 343 local to the PCP Server and to each the decision-making process at 344 the Application Server side or network middle box node. 346 5.1. PCP Request and Responses 348 The PCP client follows the steps of generating the PEER and MAP 349 opcodes request and response as described in [Flowdata]. The 350 FEEDBACK option is included in the request and response according to 351 the format described in this section. 353 Option Name: FEEDBACK 354 Number: to be assigned by IANA 355 Purpose: Describe to the network information on the end-user 356 application and user context (e.g., device characteristics, 357 buffering status as indication of the network conditions, 358 location, environment light/noise, mobility status), and 359 information on the content that can be provided by the application 360 server. 361 Valid for opcodes: PEER and MAP 362 Length: 16 Octets 363 May appear in: request. May appear in response only if it 364 appeared in the associated request 365 Maximum occurrences: 1 367 The FEEDBACK option request has the following format: 369 0 1 2 3 370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 |Option code=TBA|Reserved Option| Option Length= 16 | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Reserved | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | SRPW | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | SRPH | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | BLS | SSz |MStat| Location | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 1: FEEDBACK Option Request 385 The fields are described as follows: 387 o SRPW: Screen Resolution Pixels in Width, giving the number of 388 pixels in width for the screen. This field takes a value 0 if no 389 information/update is required to be sent. 390 o SRPH: Screen Resolution Pixels in Height, giving the number of 391 pixels in height for the screen. This field takes a value 0 if no 392 information/update is required to be sent. 393 o BLS: Battery Level Status. The following values are defined: 395 * 0 if no information/update is required to be sent 396 * 1= fading, 397 * 2= weak, 398 * 3= medium, 399 * 4 = high, 400 * 5= very high. 401 o SSz: Screen Size of the device. The following values are defined: 403 * 0 if no information/update is required to be sent, 404 * 1= very small, 405 * 2= small, 406 * 3= medium, 407 * 4= big, 408 * 5= very big. 409 o MStat: User activity and mobility status. The following values 410 are defined: 412 * 0 if no information/update is required to be sent 413 * 1 = static, 414 * 2 = weak mobility (e.g., walking), 415 * 3= regular mobility (e.g., running), 416 * 4 = high mobility (e.g., in train) 418 o Location: Gives the user location. This field takes a value 0 if 419 no information/update is required to be sent. 421 The FEEDBACK option response has the following format: 423 0 1 2 3 424 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |Option code=TBA|Reserved Option| Option Length= 16 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | PCP Server Notification | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | SRPW | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | SRPH | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | BLS | SSz |MStat| Location | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 2: FEEDBACK Option Response 439 The field PCP Server Notification shows the response status for the 440 sent request: 442 o 0= request cannot be satisfied, 443 o 1= the request can be partially satisfied, 444 o 2= the request can be satisfied, 445 o 3= the request can be fully satisfied. 447 The content of the remaining fields are echoed from the request. 449 6. Security Consideration 451 The security consideration for PCP in RFC 6887 [RFC6887] and the PCP 452 client authentication [PCPAuthentication] are sufficient to ensure 453 security and host authorization for the proposed PCP extension in 454 this document. 456 7. IANA Consideration 458 IANA is requested to assign a new PCP option called FEEDBACK in the 459 IANA registry for PCP [pcp-iana]. 461 8. Acknowledgements 463 Thanks for Wu-Chi Feng and Muthaiah Venkatachalam who provided 464 valuable comments on this work. And thanks for Tirumaleswar Reddy 465 for all his comments and guidelines to prepare this version of the 466 draft. 468 9. References 470 9.1. Normative References 472 [I-D.ietf-pcp-server-selection] 473 Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 474 Reddy, "PCP Server Selection", draft-ietf-pcp-server- 475 selection-06 (work in progress), August 2014. 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [RFC6887] Wing, D., "Port Control Protocol (PCP)", RFC 6887, April 481 2013. 483 9.2. Informative References 485 [Flowdata] 486 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 487 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 489 [I-D.ietf-httpbis-http2] 490 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 491 Protocol version 2", draft-ietf-httpbis-http2-15 (work in 492 progress), October 2014. 494 [PCPAuthentication] 495 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 496 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 497 authentication-02 (work in progress), October 2013. 499 [PCPProxy] 500 Boucadair, M., Penno, R., and D. Ding, "Port Control 501 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-03 502 (work in progress), June 2013. 504 [RFC2616] Fielding, R., "Hypertext Transfer Protocol -- HTTP/1.1", 505 RFC 2616, June 1999. 507 [RFC3840] Rosenberg, J., "Indicating User Agent Capabilities in 508 Session Initiation Protocol (SIP)", RFC 3840, August 2004. 510 [RFC4566] Handley, M., "SDP: Session Description Protocol", RFC 511 4566, July 2006. 513 [ServiceFunctions] 514 Liu, W., Li, H., Huang, O., Boucadair, M., Leymann, N., 515 Cao, Z., and J. Hu, "Service Function Chaining Use Cases", 516 draft-liu-sfc-use-cases-00 (work in progress), October 517 2013. 519 Appendix A. Existing Protocols of Relevance to User's Feedback 520 Information and their Limitations 522 Some existing protocols can convey devices characteristics and 523 information on the user, however with limited applicability. 524 Examples are: 526 o SIP [RFC3840] 528 * Provides a specification for capabilities and characteristics 529 in SIP User Agent (UA). Capabilities and characteristics 530 information is carried as parameters of the Contact header 531 field and can be used within REGISTER requests and responses, 532 OPTIONS responses, and requests and responses creating dialogs 533 (such as INVITE). 535 * SIP limitation for the explained use-cases: i) the need of 536 adding the SIP protocol stack in video streaming servers, ii) 537 SIP does not rely on network entities and is mainly an 538 application specific protocol, and iii) SIP is not appropriate 539 for "live" real-time control with no network priority to SIP 540 controls. 542 * Other Signalling protocols such as IAX are used to establish 543 media sessions. 545 o HTTP 1.1 [RFC2616] and HTTP2.0 [I-D.ietf-httpbis-http2] 547 * HTTP can incorporate information on the device and the user in 548 its headers (e.g. Accept or Use-Agent headers), however this 549 will not be a generic solution to any underlying transport 550 protocol. 552 * Also, HTTP by its nature is a stateless protocol and activating 553 HTTP proxy functionality impacts the performance of the network 554 which limits the communication through proxies. 556 o SDP [RFC4566] 558 * SDP is meant to provide a standard representation for session 559 description without incorporating a transport protocol, without 560 a focus on user's feedback information 562 * SDP is used for the session negotiation at the beginning of the 563 session and so for the devices characteristics and the user 564 information could not be directly signaled in real-time 566 * SDP uses protocols as SIP and RTSP that are not intercepted by 567 middle nodes in the network which limits its applicability. 569 * SDP is not used in some non-SIP deployement contexts. 571 Authors' Addresses 573 Hassnaa Moustafa 574 Intel Corporation 575 Hillsboro, OR 97124 576 USA 578 EMail: hassnaa.moustafa@intel.com 580 Danny Moses 581 Intel Corporation 583 EMail: danny.moses@intel.com 585 Mohamed Boucadair 586 France Telecom 587 Rennes 35000 588 France 590 EMail: mohamed.boucadair@orange.com