idnits 2.17.1 draft-jesske-sipcore-sip-tree-cap-indicators-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 : ---------------------------------------------------------------------------- ** 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 197: '...dia capabilities SHOULD include all th...' RFC 2119 keyword, line 199: '...t of feature capability indicators MAY...' RFC 2119 keyword, line 202: '... 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 (June 18, 2018) is 2132 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 R. Jesske, Ed. 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational June 18, 2018 5 Expires: December 20, 2018 7 Internet Assigned Numbers Authority (IANA) Registration of the Session 8 Initiation Protocol (SIP) Feature-Capability indicators 9 draft-jesske-sipcore-sip-tree-cap-indicators-00 11 Abstract 13 This document registers with IANA SIP Feature-Capability indicators 14 in the "SIP Feature-Capability Indicator Registration Tree" of the 15 IANA "Proxy-Feature Feature-Capability Indicator Trees" registry for 16 use with the SIP Feature-Caps header field and defines their usage 17 and interpretation. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 20, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SIP Feature-Capability indicators . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.2. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.3. Application . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.4. Data . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5.5. Control . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.6. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5.7. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.8. Message . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.9. Interactive Connectivity Establishment . . . . . . . . . 12 67 5.10. Application Subtype . . . . . . . . . . . . . . . . . . . 13 68 5.11. Fax . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 72 7.2. Informative References . . . . . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 RFC 6809 [2] specifies the SIP Feature-Caps header field that conveys 78 feature-capability indicators that are used to indicate support of 79 features and capabilities for SIP entities that are not represented 80 by the Uniform Resource Identifier (URI) of the Contact header field. 81 RFC 6809 [2] also creates a new IANA registry, "Proxy-Feature 82 Feature-Capability Indicator Trees", for registering feature- 83 capability indicators including a SIP feature-capability indicator 84 tree for registering SIP feature-capability indicators that is 85 similar to the media feature tag SIP tree defined in RFC 3840 [3]. 86 To date only one feature-capability indicator, sip.607 (RFC 8197 87 [14]) has been included in the SIP feature-capability indicator tree. 89 This document populates this SIP tree with some additional feature- 90 capability indicators that are based upon those already defined in 91 RFC 3840 [3], RFC 4569 [4], RFC 5768 [5], RFC 5688 [6] and RFC 6913 92 [7] and also defines an additional SIP feature-capability indicator 93 "Contact-features" that allows an intermediary to indicate a contact 94 address and the capabilities supported by that intermediary if SIP 95 Requests are sent to that contact address. 97 2. Motivation 99 SIP sessions often involve intermediaries (typically acting as 100 B2BUAs) that in addition to forwarding SIP requests and responses can 101 also act as UAs to perform more complex manipulations of the session. 102 Examples of such intermediaries include IP PBXs (Internet Protocol 103 Private Branch Exchanges), Telephony Call Feature Application Servers 104 and Session Transfer Anchor Points. Often the manipulations of the 105 session by the intermediary are initiated by one of the UAs in the 106 session sending a request (such as REFER request) to the intermediary 107 to for example transfer the session or create a conference. 108 Additionally UAs may also need to subscribe to events related to the 109 session with the intermediary accepting such subscriptions and 110 providing the notification of event state changes. 112 Typically such functionality has been achieved by sending such REFER 113 and SUBSCRIBE requests within the established dialog for the session, 114 with the intermediary then intercepting and processing the REFER or 115 SUBSCRIBE request rather than forwarding it to the remote UAS. 116 However such dialog reuse has been problematic and RFC 6665 [8] has 117 deprecated dialog reuse (except for legacy interoperability). 118 However, in order to avoid reusing the same dialog as the session and 119 achieve equivalent functionality when interacting with intermediaries 120 using for instance REFER request requires that the UA obtain the 121 Globally Routable User Agent URI (GRUU) of the intermediary and also 122 know that the intermediary supports the relevant capabilities such as 123 the required SIP methods (i.e. REFER) as well as the needed SIP 124 extensions, (such as target dialog extension specified in RFC 4538 in 125 [9]). 127 Typically B2BUAs have acted as two UAs back-to-back with the Contact 128 URI being the URI of the B2BUA. However this means that GRUU of the 129 UA is overwritten by the B2BUA and the meaning of the Contact header 130 field parameters becomes obscure. Do the Contact header field 131 parameters reflect the capabilities of the Contact address (i.e. the 132 B2BUA) or do they reflect the capabilities of the remote UA? If they 133 reflect the capabilities of the B2BUA then the identification of the 134 capabilities of the remote UA have been lost. If they reflect the 135 capabilities of the remote UA then they falsely identify that the 136 B2BUA contact address has the capabilities of the remote UA. 138 Another use case for B2BUAs is in control of Application Level 139 Gateways (ALGs). These ALGs are controlled by SIP intermediaries 140 that act as routing B2BUs and perform media functions such as IP 141 address translation, transcoding, and media policing. Such ALGs may 142 only support some media types while blocking others. It is useful if 143 the media types that are allowed can be communicated to other 144 entities in the SIP signaling so that fruitless attempts to establish 145 sessions with media types that will not be allowed are not 146 attempted.Such functionality is required by 3GPP IMS (IP Multimedia 147 Subsystem) to avoid unnecessary failed session establishment 148 attempts. 150 What is needed is a way for intermediaries to pass the remote UA's 151 contact address and capabilities transparently in the Contact header 152 field while being able to indicate their own contact address (i.e 153 GRUU) and associated capabilities to the UA. 155 RFC 6809 [2] provides that addresses of intermediaries can be 156 communicated as a value of an associated feature-capability 157 indicator. What is needed is a feature capability indicator to 158 communicate the contact address GRUU (Globally Routable User Agent 159 URI of the intermediary along with the associated media feature- 160 capability indicators tags representing the capabilities supported by 161 that of the intermediary if SIP Requests are sent to that contact 162 address. The feature-capability indicators for communicating SIP 163 related capabilities (e.g. supported SIP Methods and extensions) also 164 need to be registered in the SIP tree in order to allow an 165 intermediary to indicate the SIP features it supports when forwarding 166 SIP requests or the media capabilities it supports as an ALG. 168 3. SIP Feature-Capability indicators 170 This document defines a new Feature-Capability indicator in the SIP 171 tree: 173 sip.contact 175 The sip.contact Feature-Capability indicator provides a GRUU as the 176 contact address of the intermediary along with a list of all the 177 media feature tags representing the capabilities of the intermediary 178 supported by that intermediary if SIP Requests areent to that contact 179 address. 181 The following media feature tags from RFC 3840 [3]", RFC 4569 [4], 182 RFC 5768 [5], RFC 5688 [6] and RFC 6913 [7] are considered to be 183 useful to also be defined as Feature-Capability indicators: 185 sip.audio 186 sip.application 187 sip.data 188 sip.control 189 sip.video 190 sip.text 191 sip.message 192 sip.ice 193 sip.app-subtype 194 sip.fax 196 An intermediary that includes at least feature capability indicator 197 of one of the above media capabilities SHOULD include all the feature 198 capability indicators for the media it will allow. The absence of a 199 media capability from the list of feature capability indicators MAY 200 be interpreted by another entity as indicating that this media is not 201 allowed. The lack of indication of any of the above media 202 capabilities SHOULD be interpreted as inconclusive information about 203 what media is allowed or not allowed. 205 The following media feature tags from RFC 3840 [3], RFC 4235 [10] and 206 RFC 5626 [11] are currently NOT considered to be useful to be defined 207 as Feature-Capability indicators since they do not represent stream 208 types likely to be implemented by an intermediary: 210 sip.automata 211 sip.class 212 sip.mobility 213 sip.actor 214 sip.byeless 215 sip.rendering 216 sip.instance 217 sip.duplex 218 sip.description 219 sip.events 220 sip.priority 221 sip.methods 222 sip.extensions 223 sip.schemes 224 sip.isfocus 226 4. Security Considerations 228 The security considerations in RFC 3840 [3] and RFC 6809 [2] apply to 229 the use of Feature-capability indicators in the SIP tree. 231 5. IANA Considerations 233 This specification registers the following new feature-capability 234 indicators in the SIP tree per the procedures defined in RFC 6809 235 [11]. 237 5.1. Contact 239 Feature-capability indicator name: sip.contact 241 Description: 243 This Feature-capability indicator indicator provides a GRUU as the 244 contact address of the intermediary along with a list of all the 245 media feature tags representing the capabilities of the intermediary 246 supported by that intermediary if SIP Requests are sent to that 247 contact address. 249 Feature-capability indicator specification reference: The present 250 document. 252 Additional information: 254 Values appropriate for use with this Feature-Capability indicator: 256 String with an equality relationship. The Syntax for the string is 257 the same as the of the contents of the Contact header field defined 258 in RFC 3261 [1]. 260 This Feature-Capability indicator is most useful in a communications 261 application, such as an IP-PBX or conference bridge for providing a 262 contact address and the capabilities of a network intermediary at 263 that contact address. 265 Examples of typical use: An conference server indicating that it is 266 capable of accepting SIP REFER requests for inviting 3rd parties to a 267 conference. 269 Security Considerations: Security considerations for this Feature- 270 capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3]. 272 5.2. Audio 274 Feature-capability indicator name: sip.audio 276 Description: 278 This Feature-capability indicator indicates that the intermediary 279 supports audio as a streaming media type for sessions established via 280 it. 282 Feature-capability indicator specification reference: RFC 3840 [3]. 284 Additional information: 286 Values appropriate for use with this Feature-Capability indicator: 287 Boolean. 289 This Feature-Capability indicator is most useful in a communications 290 application for describing the capabilities of a network 291 intermediary, such as an IP-PBX or conference bridge. 293 Examples of typical use: An IP PBX indicating that it is capable of 294 accepting and initiating sessions with audio as a streaming media 295 type. 297 Security Considerations: Security considerations for this Feature- 298 capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3]. 300 5.3. Application 302 Feature-capability indicator name: sip.application 304 Description: 306 This Feature-capability indicator indicates that the intermediary 307 supports application as a streaming media type for sessions 308 established via it. 310 Feature-capability indicator specification reference: RFC 3840 [3]. 312 Additional information: 314 Values appropriate for use with this Feature-Capability indicator: 315 Boolean. 317 This Feature-Capability indicator is most useful in a communications 318 application for describing the capabilities of a network 319 intermediary, such as an IP-PBX or conference bridge. 321 Examples of typical use: An IP PBX indicating that it is capable of 322 accepting and initiating sessions with a media control application. 324 Security Considerations: Security considerations for this Feature- 325 capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3]. 327 5.4. Data 329 Feature-capability indicator name: sip.data 331 Description: 333 This Feature-capability indicator indicates that the intermediary 334 supports data as a streaming media type for sessions established via 335 it. 337 Feature-capability indicator specification reference: RFC 3840 [3]. 339 Additional information: 341 Values appropriate for use with this Feature-Capability indicator: 342 Boolean. 344 This Feature-Capability indicator is most useful in a communications 345 application for describing the capabilities of a network 346 intermediary, such as an IP-PBX or conference bridge. 348 Examples of typical use: An IP PBX indicating that it is capable of 349 accepting and initiating sessions with data as a streaming media 350 type. 352 Security Considerations: Security considerations for this Feature- 353 capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3]. 355 5.5. Control 357 Feature-capability indicator name: sip.control 359 Description: 361 This Feature-capability indicator indicates that the intermediary 362 supports control as a streaming media type for sessions established 363 via it. 365 Feature-capability indicator specification reference: RFC 3840 [3]. 367 Additional information: 369 Values appropriate for use with this Feature-Capability indicator: 370 Boolean. 372 This Feature-Capability indicator is most useful in a communications 373 application for describing the capabilities of a network 374 intermediary, such as an IP-PBX or conference bridge. 376 Examples of typical use: A conference bridge indicating that it is 377 capable of supporting a floor control application. 379 Security Considerations: Security considerations for this Feature- 380 capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3]. 382 5.6. Video 384 Feature-capability indicator name: sip.video 386 Description: 388 This Feature-capability indicator indicates that the intermediary 389 supports video as a streaming media type for sessions established via 390 it. 392 Feature-capability indicator specification reference: RFC 3840 [3]. 394 Additional information: 396 Values appropriate for use with this Feature-Capability indicator: 397 Boolean. 399 This Feature-Capability indicator is most useful in a communications 400 application for describing the capabilities of a network 401 intermediary, such as an IP-PBX or conference bridge. 403 Examples of typical use: An IP PBX indicating that it is capable of 404 accepting and initiating sessions with video as a streaming media 405 type. 407 Security Considerations: Security considerations for this Feature- 408 capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3]. 410 5.7. Text 412 Feature-capability indicator name: sip.text 414 Description: 416 This Feature-capability indicator indicates that the intermediary 417 supports text as a streaming media type for sessions established via 418 it. 420 Feature-capability indicator specification reference: RFC 3840 [3]. 422 Additional information: 424 Values appropriate for use with this Feature-Capability indicator: 425 Boolean. 427 This Feature-Capability indicator is most useful in a communications 428 application for describing the capabilities of a network 429 intermediary, such as an IP-PBX or conference bridge. 431 Examples of typical use: An IP PBX indicating that it is capable of 432 accepting and initiating sessions with text as a streaming media 433 type. 435 Security Considerations: Security considerations for this Feature- 436 capability indicator are discussed in RFC 6809 [2] and RFC 3840 [3]. 438 5.8. Message 440 Feature-capability indicator name: sip.message 442 Descrition: 444 This Feature-capability indicator indicates that the intermediary 445 supports message as a streaming media type for sessions established 446 via it. 448 Feature-capability indicator specification reference: RFC 4569 [4]. 450 Additional information: 452 Values appropriate for use with this Feature-Capability indicator: 453 Boolean. 455 This Feature-Capability indicator is most useful in a communications 456 application for describing the capabilities of a network 457 intermediary, such as an IP-PBX or conference bridge. 459 Examples of typical use: An IP PBX indicating that it is capable of 460 accepting and initiating sessions with message as a streaming media 461 type. 463 Security Considerations: Security considerations for this Feature- 464 capability indicator are discussed in RFC 6809 [2], RFC 3840 [3] and 465 RFC 4569 [4]. 467 5.9. Interactive Connectivity Establishment 469 Feature-capability indicator name: sip.ice 471 Description: 473 This Feature-capability indicator indicates that the intermediary 474 supports Interactive Connectivity Establishment (ICE) for sessions 475 established via it. 477 Feature-capability indicator specification reference: RFC 5768 [5]. 479 Additional information: 481 Values appropriate for use with this Feature-Capability indicator: 482 Boolean. 484 This Feature-Capability indicator is most useful in a communications 485 application for describing the capabilities of a network 486 intermediary, such as an IP-PBX or conference bridge. 488 Examples of typical use: An IP PBX indicating that it is capable of 489 using ICE to establish media connectivity for sessions. 491 Security Considerations: Security considerations for this Feature- 492 capability indicator are discussed in RFC 6809 [2], RFC 3840 [3] and 493 RFC 5768 [5]. 495 5.10. Application Subtype 497 Feature-capability indicator name: sip.app-subtype 499 Description: 501 This Feature-capability indicator indicates the MIME application 502 subtypes supported by the intermediary for purposes of streaming 503 media for sessions established via it. 505 Feature-capability indicator specification reference: RFC 5688 [6]. 507 Additional information: 509 Values appropriate for use with this Feature-Capability indicator: 510 Token (equality relationship). 512 This Feature-Capability indicator is most useful in a communications 513 application for describing the capabilities of a network 514 intermediary, such as an IP-PBX or conference bridge. 516 Examples of typical use: A conference server indicating that it 517 supports an application specific media burst control protocol for 518 Push to Talk sessions. 520 Security Considerations: Security considerations for this Feature- 521 capability indicator are discussed in RFC 6809 [2], RFC 3840 [3] and 522 RFC 5688 [6]. 524 5.11. Fax 526 Feature-capability indicator name: sip.fax 528 Description: 530 This Feature-capability indicator indicates whether an intermediary 531 accepts sessions using the ITU-T T.38 [15] fax protocol ("t38") or 532 the passthrough method of fax transmission using the ITU-T G.711 [16] 533 audio codec ("passthrough"). 535 Feature-capability indicator specification reference: RFC 6913 [7]. 537 Additional information: 539 Values appropriate for use with this Feature-Capability indicator: 540 Token with an equality relationship. Values are: 542 t38: The device supports the "image/t38" media type (RFC 3326) [12] 543 and implements ITU-T T.38 [15] for transporting the ITU-T T.30 [17] 544 and ITU-T T.4 [18] fax data over IP. 546 passthrough: The device supports the "audio/pcmu" and "audio/ pcma" 547 media types (RFC4856) [13] for transporting ITU-T T.30 [17] and ITU-T 548 T.4 [18] fax data using the ITU-T G.711 [16] audio codec. 550 This Feature-Capability indicator is most useful in a communications 551 application for describing the capabilities of a network 552 intermediary, such as an IP-PBX or conference bridge. 554 Examples of typical use: A conference bridge indicating that it is 555 capable of distributing T.38 fax media to the participants in a 556 conference. 558 Security Considerations: Security considerations for this Feature- 559 capability indicator are discussed in RFC 6809 [2], RFC 3840 [3] and 560 RFC 6913 [7]. 562 6. Acknowledgements 564 This documet was generated out of draft-allen-sipcore-sip-tree-cap- 565 indicator which was not progressed. This document draws heavily on 566 text from the earlier work on RFC 6809 [2], RFC 3840 [3], RFC 4569 567 [4], RFC 5768 [5], RFC 5688 [6] and RFC 6913 [7]. The author would 568 like to thank the authors of these RFCs: Christer Holmber, Ivo 569 Sedlacek, Hadriel Kaplan, Jonathan Rosenberg Henning Schulzrinne, 570 Paul Kyzivat, Gonzalo Camarillo, D Hanes, G Salgueiro and K Fleming 571 for their earlier work. 573 7. References 575 7.1. Normative References 577 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 578 A., Peterson, J., Sparks, R., Handley, M., and E. 579 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 580 DOI 10.17487/RFC3261, June 2002, 581 . 583 [2] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 584 Indicate Support of Features and Capabilities in the 585 Session Initiation Protocol (SIP)", RFC 6809, 586 DOI 10.17487/RFC6809, November 2012, 587 . 589 [3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 590 "Indicating User Agent Capabilities in the Session 591 Initiation Protocol (SIP)", RFC 3840, 592 DOI 10.17487/RFC3840, August 2004, 593 . 595 [4] Camarillo, G., "Internet Assigned Number Authority (IANA) 596 Registration of the Message Media Feature Tag", RFC 4569, 597 DOI 10.17487/RFC4569, July 2006, 598 . 600 [5] Rosenberg, J., "Indicating Support for Interactive 601 Connectivity Establishment (ICE) in the Session Initiation 602 Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April 603 2010, . 605 [6] Rosenberg, J., "A Session Initiation Protocol (SIP) Media 606 Feature Tag for MIME Application Subtypes", RFC 5688, 607 DOI 10.17487/RFC5688, January 2010, 608 . 610 [7] Hanes, D., Salgueiro, G., and K. Fleming, "Indicating Fax 611 over IP Capability in the Session Initiation Protocol 612 (SIP)", RFC 6913, DOI 10.17487/RFC6913, March 2013, 613 . 615 7.2. Informative References 617 [8] Roach, A., "SIP-Specific Event Notification", RFC 6665, 618 DOI 10.17487/RFC6665, July 2012, 619 . 621 [9] Rosenberg, J., "Request Authorization through Dialog 622 Identification in the Session Initiation Protocol (SIP)", 623 RFC 4538, DOI 10.17487/RFC4538, June 2006, 624 . 626 [10] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An 627 INVITE-Initiated Dialog Event Package for the Session 628 Initiation Protocol (SIP)", RFC 4235, 629 DOI 10.17487/RFC4235, November 2005, 630 . 632 [11] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 633 "Managing Client-Initiated Connections in the Session 634 Initiation Protocol (SIP)", RFC 5626, 635 DOI 10.17487/RFC5626, October 2009, 636 . 638 [12] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 639 Header Field for the Session Initiation Protocol (SIP)", 640 RFC 3326, DOI 10.17487/RFC3326, December 2002, 641 . 643 [13] Casner, S., "Media Type Registration of Payload Formats in 644 the RTP Profile for Audio and Video Conferences", 645 RFC 4856, DOI 10.17487/RFC4856, February 2007, 646 . 648 [14] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", 649 RFC 8197, DOI 10.17487/RFC8197, July 2017, 650 . 652 [15] International Telecommunication Union, "Procedures for 653 real-time Group 3 facsimile communication over IP 654 Networks", ITU-T Recommendation T.38, October 2010. 656 [16] International Telephone and Telegraph Consultative 657 Committee, "Pulse Code Modulation (PCM) of Voice 658 Frequencies", CCITT Recommendation G.711, 1972. 660 [17] International Telecommunication Union, "Procedures for 661 document facsimile transmission in the general switched 662 telephone network", ITU-T Recommendation T.30, September 663 2005. 665 [18] International Telecommunication Union, "Standardization of 666 Group 3 facsimile terminals for document transmission", 667 ITU-T Recommendation T.4, July 2003. 669 Author's Address 671 Roland Jesske (editor) 672 Deutsche Telekom 673 Heinrich-Hertz Str. 3-7 674 Darmstadt 64295 675 Germany 677 Email: r.jesske@telekom.de