idnits 2.17.1 draft-allen-sipcore-sip-tree-cap-indicators-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 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 203: '...dia capabilities SHOULD include all th...' RFC 2119 keyword, line 205: '...t of feature capability indicators MAY...' RFC 2119 keyword, line 208: '... capabilities SHOULD be interpreted ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2018) is 2290 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sipcore Working Group A. Allen, Ed. 3 Internet-Draft Blackberry 4 Intended status: Informational R. Jesske 5 Expires: July 22, 2018 Deutsche Telekom 6 January 18, 2018 8 Internet Assigned Numbers Authority (IANA) Registration of the Session 9 Initiation Protocol (SIP) Feature-Capability indicators 10 draft-allen-sipcore-sip-tree-cap-indicators-02 12 Abstract 14 This document registers with IANA SIP Feature-Capability indicators 15 in the "SIP Feature-Capability Indicator Registration Tree" of the 16 IANA "Proxy-Feature Feature-Capability Indicator Trees" registry for 17 use with the SIP Feature-Caps header field and defines their usage 18 and interpretation. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 22, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. SIP Feature-Capability indicators . . . . . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.3. Application . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.4. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.5. Control . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.6. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.7. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.8. Message . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.9. Interactive Connectivity Establishment . . . . . . . . . . 12 72 5.10. Application Subtype . . . . . . . . . . . . . . . . . . . 12 73 5.11. Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 RFC 6809 [1] specifies the SIP Feature-Caps header field that conveys 86 feature-capability indicators that are used to indicate support of 87 features and capabilities for SIP entities that are not represented 88 by the Uniform Resource Identifier (URI) of the Contact header field. 89 RFC 6809 [1] also creates a new IANA registry, "Proxy-Feature 90 Feature-Capability Indicator Trees", for registering feature- 91 capability indicators including a SIP feature-capability indicator 92 tree for registering SIP feature-capability indicators that is 93 similar to the media feature tag SIP tree defined in RFC 3840 [2]. 94 To date only one feature-capability indicator, sip.607 (RFC 8197 [8]) 95 has been included in the SIP feature-capability indicator tree. 97 This document populates this SIP tree with some additional feature- 98 capability indicators that are based upon those already defined in 99 RFC 3840 [2], RFC 4569 [3], RFC 5768 [4], RFC 5688 [5] and RFC 6913 100 [6] and also defines an additional SIP feature-capability indicator 101 "Contact-features" that allows an intermediary to indicate a contact 102 address and the capabilitie supported by that intermediary if SIP 103 Requests are sent to that contact address. 105 2. Motivation 107 SIP sessions often involve intermediaries (typically acting as 108 B2BUAs) that in addition to forwarding SIP requests and responses can 109 also act as UAs to perform more complex manipulations of the session. 110 Examples of such intermediaries include IP PBXs (Internet Protocol 111 Private Branch Exchanges), Telephony Call Feature Application Servers 112 and Session Transfer Anchor Points. Often the manipulations of the 113 session by the intermediary are initiated by one of the UAs in the 114 session sending a request (such as REFER request) to the intermediary 115 to for example transfer the session or create a conference. 116 Additionally UAs may also need to subscribe to events related to the 117 session with the intermediary accepting such subscriptions and 118 providing the notification of event state changes. 120 Typically such functionality has been achieved by sending such REFER 121 and SUBSCRIBE requests within the established dialog for the session, 122 with the intermediary then intercepting and processing the REFER or 123 SUBSCRIBE request rather than forwarding it to the remote UAS. 124 However such dialog reuse has been problematic and RFC 6665 [9] has 125 deprecated dialog reuse (except for legacy interoperability). 126 However, in order to avoid reusing the same dialog as the session and 127 achieve equivalent functionality when interacting with intermediaries 128 using for instance REFER request requires that the UA obtain the 129 Globally Routable User Agent URI (GRUU) of the intermediary and also 130 know that the intermediary supports the relevant capabilities such as 131 the required SIP methods (i.e. REFER) as well as the needed SIP 132 extensions, (such as target dialog extension specified in RFC 4538 in 133 [10]). 135 Typically B2BUAs have acted as two UAs back-to-back with the Contact 136 URI being the URI of the B2BUA. However this means that GRUU of the 137 UA is overwritten by the B2BUA and the meaning of the Contact header 138 field parameters becomes obscure. Do the Contact header field 139 parameters reflect the capabilities of the Contact address (i.e. the 140 B2BUA) or do they reflect the capabilities of the remote UA? If they 141 reflect the capabilities of the B2BUA then the identification of the 142 capabilities of the remote UA have been lost. If they reflect the 143 capabilities of the remote UA then they falsely identify that the 144 B2BUA contact address has the capabilities of the remote UA. 146 Another use case for B2BUAs is in control of Application Level 147 Gateways (ALGs). These ALGs are controlled by SIP intermediaries 148 that act as routing B2BUs and perform media functions such as IP 149 address translation, transcoding, and media policing. Such ALGs may 150 only support some media types while blocking others. It is useful if 151 the media types that are allowed can be communciated to other 152 entities in the SIP signaling so that fruitless attempts to establish 153 sessions with media types that will not be allowed are not 154 attempted.Such functionality is required by 3GPP IMS (IP Multimedia 155 Subsystem) to avoid unnecessary failed session establishment 156 attempts. 158 What is needed is a way for intermediaries to pass the remote UA's 159 contact address and capabilities transparently in the Contact header 160 field while being able to indicate their own contact address (i.e 161 GRUU) and associated capabilities to the UA. 163 RFC 6809 [1] provides that addresses of intermediaries can be 164 communicated as a value of an associated feature-capability 165 indicator. What is needed is a feature capability indicator to 166 communicate the contact address GRUU (Globally Routable User Agent 167 URI of the intermediary along with the associated media feature- 168 capability indicators tags representing the capabilities supported by 169 that of the intermediary if SIP Requests are sent to that contact 170 address. The feature-capability indicators for communicating SIP 171 related capabilities (e.g. supported SIP Methods and extensions) also 172 need to be registered in the SIP tree in order to allow an 173 intermediary to indicate the SIP features it supports when forwarding 174 SIP requests or the media capabilities it supports as an ALG. 176 3. SIP Feature-Capability indicators 178 This document defines a new Feature-Capability indicator in the SIP 179 tree: 180 sip.contact 182 The sip.contact Feature-Capability indicator provides a GRUU as the 183 contact address of the intermediary along with a list of all the 184 Fmedia feature tags representing the capabilities of the intermediary 185 supported by that intermediary if SIP Requests areent to that contact 186 address. 188 The following media feature tags from RFC 3840 [2]", RFC 4569 [3], 189 RFC 5768 [4], RFC 5688 [5] and RFC 6913 [6] are considered to be 190 useful to also be defined as Feature-Capability indicators: 191 sip.audio 192 sip.application 193 sip.data 194 sip.control 195 sip.video 196 sip.text 197 sip.message 198 sip.ice 199 sip.app-subtype 200 sip.fax 202 An intermediary that includes at least feature capability indicator 203 of one of the above media capabilities SHOULD include all the feature 204 capability indicators for the media it will allow. The absence of a 205 media capability from the list of feature capability indicators MAY 206 be interpreted by another entity as indicating that this media is not 207 allowed. The lack of indication of any of the above media 208 capabilities SHOULD be interpreted as inconclusive information about 209 what media is allowed or not allowed. 211 The following media feature tags from RFC 3840 [2], RFC 4235 [11] and 212 RFC 5626 [12] are currently NOT considered to be useful to be defined 213 as Feature-Capability indicators since they do not represent stream 214 types likely to be implemented by an intermediary: 215 sip.automata 216 sip.class 217 sip.mobility 218 sip.actor 219 sip.byeless 220 sip.rendering 221 sip.instance 222 sip.duplex 223 sip.description 224 sip.events 225 sip.priority 226 sip.methods 227 sip.extensions 228 sip.schemes 229 sip.isfocus 231 4. Security Considerations 233 The security considerations in RFC 3840 [2] and RFC 6809 [1] apply to 234 the use of Feature-capability indicators in the SIP tree. 236 5. IANA Considerations 238 This specification registers the following new feature-capability 239 indicators in the SIP tree per the procedures defined in RFC 6809 240 [12]. 242 5.1. Contact 244 Feature-capability indicator name: sip.contact 246 Description: 247 This Feature-capability indicator indicator provides a GRUU as the 248 contact address of the intermediary along with a list of all the 249 media feature tags representing the capabilities of the 250 intermediary supported by that intermediary if SIP Requests are 251 sent to that contact address. 253 Feature-capability indicator specification reference: The present 254 document. 256 Additional information: 258 Values appropriate for use with this Feature-Capability 259 indicator: 261 String with an equality relationship. The Syntax for the 262 string is the same as the of the contents of the Contact header 263 field defined in RFC 3261 [7]. 265 This Feature-Capability indicator is most useful in a 266 communications application, such as an IP-PBX or conference 267 bridge for providing a contact address and the capabilities of 268 a network intermediary at that contact address. 270 Examples of typical use: An conference server indicating that 271 it is capable of accepting SIP REFER requests for inviting 3rd 272 parties to a conference. 274 Security Considerations: Security considerations for this 275 Feature-capability indicator are discussed in RFC 6809 [1] and 276 RFC 3840 [2]. 278 5.2. Audio 280 Feature-capability indicator name: sip.audio 282 Description: 283 This Feature-capability indicator indicates that the intermediary 284 supports audio as a streaming media type for sessions established 285 via it. 287 Feature-capability indicator specification reference: RFC 3840 288 [2]. 290 Additional information: 292 Values appropriate for use with this Feature-Capability 293 indicator: Boolean. 295 This Feature-Capability indicator is most useful in a 296 communications application for describing the capabilities of a 297 network intermediary, such as an IP-PBX or conference bridge. 299 Examples of typical use: An IP PBX indicating that it is 300 capable of accepting and initiating sessions with audio as a 301 streaming media type. 303 Security Considerations: Security considerations for this 304 Feature-capability indicator are discussed in RFC 6809 [1] and 305 RFC 3840 [2]. 307 5.3. Application 309 Feature-capability indicator name: sip.application 311 Description: 312 This Feature-capability indicator indicates that the intermediary 313 supports application as a streaming media type for sessions 314 established via it. 316 Feature-capability indicator specification reference: RFC 3840 317 [2]. 319 Additional information: 321 Values appropriate for use with this Feature-Capability 322 indicator: Boolean. 324 This Feature-Capability indicator is most useful in a 325 communications application for describing the capabilities of a 326 network intermediary, such as an IP-PBX or conference bridge. 328 Examples of typical use: An IP PBX indicating that it is 329 capable of accepting and initiating sessions with a media 330 control application. 332 Security Considerations: Security considerations for this 333 Feature-capability indicator are discussed in RFC 6809 [1] and 334 RFC 3840 [2]. 336 5.4. Data 338 Feature-capability indicator name: sip.data 340 Description: 341 This Feature-capability indicator indicates that the intermediary 342 supports data as a streaming media type for sessions established 343 via it. 345 Feature-capability indicator specification reference: RFC 3840 346 [2]. 348 Additional information: 350 Values appropriate for use with this Feature-Capability 351 indicator: Boolean. 353 This Feature-Capability indicator is most useful in a 354 communications application for describing the capabilities of a 355 network intermediary, such as an IP-PBX or conference bridge. 357 Examples of typical use: An IP PBX indicating that it is 358 capable of accepting and initiating sessions with data as a 359 streaming media type. 361 Security Considerations: Security considerations for this 362 Feature-capability indicator are discussed in RFC 6809 [1] and 363 RFC 3840 [2]. 365 5.5. Control 367 Feature-capability indicator name: sip.control 369 Description: 370 This Feature-capability indicator indicates that the intermediary 371 supports control as a streaming media type for sessions 372 established via it. 374 Feature-capability indicator specification reference: RFC 3840 375 [2]. 377 Additional information: 379 Values appropriate for use with this Feature-Capability 380 indicator: Boolean. 382 This Feature-Capability indicator is most useful in a 383 communications application for describing the capabilities of a 384 network intermediary, such as an IP-PBX or conference bridge. 386 Examples of typical use: A conference bridge indicating that it 387 is capable of supporting a floor control application. 389 Security Considerations: Security considerations for this 390 Feature-capability indicator are discussed in RFC 6809 [1] and 391 RFC 3840 [2]. 393 5.6. Video 395 Feature-capability indicator name: sip.video 397 Description: 398 This Feature-capability indicator indicates that the intermediary 399 supports video as a streaming media type for sessions established 400 via it. 402 Feature-capability indicator specification reference: RFC 3840 403 [2]. 405 Additional information: 407 Values appropriate for use with this Feature-Capability 408 indicator: Boolean. 410 This Feature-Capability indicator is most useful in a 411 communications application for describing the capabilities of a 412 network intermediary, such as an IP-PBX or conference bridge. 414 Examples of typical use: An IP PBX indicating that it is 415 capable of accepting and initiating sessions with video as a 416 streaming media type. 418 Security Considerations: Security considerations for this 419 Feature-capability indicator are discussed in RFC 6809 [1] and 420 RFC 3840 [2]. 422 5.7. Text 424 Feature-capability indicator name: sip.text 426 Description: 427 This Feature-capability indicator indicates that the intermediary 428 supports text as a streaming media type for sessions established 429 via it. 431 Feature-capability indicator specification reference: RFC 3840 432 [2]. 434 Additional information: 436 Values appropriate for use with this Feature-Capability 437 indicator: Boolean. 439 This Feature-Capability indicator is most useful in a 440 communications application for describing the capabilities of a 441 network intermediary, such as an IP-PBX or conference bridge. 443 Examples of typical use: An IP PBX indicating that it is 444 capable of accepting and initiating sessions with text as a 445 streaming media type. 447 Security Considerations: Security considerations for this 448 Feature-capability indicator are discussed in RFC 6809 [1] and 449 RFC 3840 [2]. 451 5.8. Message 453 Feature-capability indicator name: sip.message 455 Descrition: 456 This Feature-capability indicator indicates that the intermediary 457 supports message as a streaming media type for sessions 458 established via it. 460 Feature-capability indicator specification reference: RFC 4569 461 [3]. 463 Additional information: 465 Values appropriate for use with this Feature-Capability 466 indicator: Boolean. 468 This Feature-Capability indicator is most useful in a 469 communications application for describing the capabilities of a 470 network intermediary, such as an IP-PBX or conference bridge. 472 Examples of typical use: An IP PBX indicating that it is 473 capable of accepting and initiating sessions with message as a 474 streaming media type. 476 Security Considerations: Security considerations for this 477 Feature-capability indicator are discussed in RFC 6809 [1], RFC 478 3840 [2] and RFC 4569 [3]. 480 5.9. Interactive Connectivity Establishment 482 Feature-capability indicator name: sip.ice 484 Description: 485 This Feature-capability indicator indicates that the intermediary 486 supports Interactive Connectivity Establishment (ICE) for sessions 487 established via it. 489 Feature-capability indicator specification reference: RFC 5768 490 [4]. 492 Additional information: 494 Values appropriate for use with this Feature-Capability 495 indicator: Boolean. 497 This Feature-Capability indicator is most useful in a 498 communications application for describing the capabilities of a 499 network intermediary, such as an IP-PBX or conference bridge. 501 Examples of typical use: An IP PBX indicating that it is 502 capable of using ICE to establish media connectivity for 503 sessions. 505 Security Considerations: Security considerations for this 506 Feature-capability indicator are discussed in RFC 6809 [1], RFC 507 3840 [2] and RFC 5768 [4]. 509 5.10. Application Subtype 511 Feature-capability indicator name: sip.app-subtype 513 Description: 514 This Feature-capability indicator indicates the MIME application 515 subtypes supported by the intermediary for purposes of streaming 516 media for sessions established via it. 518 Feature-capability indicator specification reference: RFC 5688 519 [5]. 521 Additional information: 523 Values appropriate for use with this Feature-Capability 524 indicator: Token (equality relationship). 526 This Feature-Capability indicator is most useful in a 527 communications application for describing the capabilities of a 528 network intermediary, such as an IP-PBX or conference bridge. 530 Examples of typical use: A conference server indicating that it 531 supports an application specific media burst control protocol 532 for Push to Talk sessions. 534 Security Considerations: Security considerations for this 535 Feature-capability indicator are discussed in RFC 6809 [1], RFC 536 3840 [2] and RFC 5688 [5]. 538 5.11. Fax 540 Feature-capability indicator name: sip.fax 542 Description: 543 This Feature-capability indicator indicates whether an 544 intermediary accepts sessions using the ITU-T T.38 [13] fax 545 protocol ("t38") or the passthrough method of fax transmission 546 using the ITU-T G.711 [14] audio codec ("passthrough"). 548 Feature-capability indicator specification reference: RFC 6913 549 [6]. 551 Additional information: 553 Values appropriate for use with this Feature-Capability 554 indicator: Token with an equality relationship. Values are: 556 t38: The device supports the "image/t38" media type (RFC 557 3326) [15] and implements ITU-T T.38 [13] for transporting 558 the ITU-T T.30 [16] and ITU-T T.4 [17] fax data over IP. 560 passthrough: The device supports the "audio/pcmu" and 561 "audio/ pcma" media types (RFC4856) [18] for transporting 562 ITU-T T.30 [16] and ITU-T T.4 [17] fax data using the ITU-T 563 G.711 [14] audio codec. 565 This Feature-Capability indicator is most useful in a 566 communications application for describing the capabilities of a 567 network intermediary, such as an IP-PBX or conference bridge. 569 Examples of typical use: A conference bridge indicating that it 570 is capable of distributing T.38 fax media to the participants 571 in a conference. 573 Security Considerations: Security considerations for this 574 Feature-capability indicator are discussed in RFC 6809 [1], RFC 575 3840 [2] and RFC 6913 [6]. 577 6. Acknowledgements 579 This document draws heavily on text from the earlier work on RFC 6809 580 [1], RFC 3840 [2], RFC 4569 [3], RFC 5768 [4], RFC 5688 [5] and RFC 581 6913 [6]. The author would like to thank the authors of these RFCs: 582 Christer Holmber, Ivo Sedlacek, Hadriel Kaplan, Jonathan Rosenberg 583 Henning Schulzrinne, Paul Kyzivat, Gonzalo Camarillo, D Hanes, G 584 Salgueiro and K Fleming for their earlier work. 586 7. References 588 7.1. Normative References 590 [1] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 591 Indicate Support of Features and Capabilities in the Session 592 Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, 593 November 2012, . 595 [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 596 User Agent Capabilities in the Session Initiation Protocol 597 (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, 598 . 600 [3] Camarillo, G., "Internet Assigned Number Authority (IANA) 601 Registration of the Message Media Feature Tag", RFC 4569, 602 DOI 10.17487/RFC4569, July 2006, 603 . 605 [4] Rosenberg, J., "Indicating Support for Interactive Connectivity 606 Establishment (ICE) in the Session Initiation Protocol (SIP)", 607 RFC 5768, DOI 10.17487/RFC5768, April 2010, 608 . 610 [5] Rosenberg, J., "A Session Initiation Protocol (SIP) Media 611 Feature Tag for MIME Application Subtypes", RFC 5688, 612 DOI 10.17487/RFC5688, January 2010, 613 . 615 [6] Hanes, D., Salgueiro, G., and K. Fleming, "Indicating Fax over 616 IP Capability in the Session Initiation Protocol (SIP)", 617 RFC 6913, DOI 10.17487/RFC6913, March 2013, 618 . 620 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 621 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 622 Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, 623 June 2002, . 625 7.2. Informative References 627 [8] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", 628 RFC 8197, DOI 10.17487/RFC8197, July 2017, 629 . 631 [9] Roach, A., "SIP-Specific Event Notification", RFC 6665, 632 DOI 10.17487/RFC6665, July 2012, 633 . 635 [10] Rosenberg, J., "Request Authorization through Dialog 636 Identification in the Session Initiation Protocol (SIP)", 637 RFC 4538, DOI 10.17487/RFC4538, June 2006, 638 . 640 [11] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE- 641 Initiated Dialog Event Package for the Session Initiation 642 Protocol (SIP)", RFC 4235, DOI 10.17487/RFC4235, November 2005, 643 . 645 [12] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing 646 Client-Initiated Connections in the Session Initiation Protocol 647 (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, 648 . 650 [13] International Telecommunication Union, "Procedures for real- 651 time Group 3 facsimile communication over IP Networks", ITU- 652 T Recommendation T.38, October 2010. 654 [14] International Telephone and Telegraph Consultative Committee, 655 "Pulse Code Modulation (PCM) of Voice Frequencies", 656 CCITT Recommendation G.711, 1972. 658 [15] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header 659 Field for the Session Initiation Protocol (SIP)", RFC 3326, 660 DOI 10.17487/RFC3326, December 2002, 661 . 663 [16] International Telecommunication Union, "Procedures for document 664 facsimile transmission in the general switched telephone 665 network", ITU-T Recommendation T.30, September 2005. 667 [17] International Telecommunication Union, "Standardization of 668 Group 3 facsimile terminals for document transmission", ITU- 669 T Recommendation T.4, July 2003. 671 [18] Casner, S., "Media Type Registration of Payload Formats in the 672 RTP Profile for Audio and Video Conferences", RFC 4856, 673 DOI 10.17487/RFC4856, February 2007, 674 . 676 Authors' Addresses 678 Andrew Allen (editor) 679 Blackberry 680 1560 Sawgrass Corporate Parkway 681 Sunrise, Florida 33323 682 USA 684 Email: aallen@blackberry.com 686 Roland Jesske 687 Deutsche Telekom 688 Heinrich-Hertz Str. 3-7 689 Darmstadt 64295 690 Germany 692 Email: r.jesske@telekom.de