idnits 2.17.1 draft-beauchamp-private-wire-10.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A single instance of the 'pw-type' parameter MUST be included with a 'Recv-Info' header to convey the type of private wire being used for the SIP dialog. The value of 'pw-type' can either be 'ringdown', 'hookswitch' or 'TOS'. By specifying a value of 'ringdown' in the 'pw-type' parameter the element MUST be used from Section 9. By specifying a value of 'hookswitch' in the 'pw-type' parameter the element MUST be used from Section 9. By specifying 'TOS'(Transmission Only Service) no additional signalling is used in complying with this specification (future specifications may provide additional functionality). TOS is normally used for interconnecting voice systems that need no signalling and are always assumed to be connected. An example might be TV audio or a Hoot line. This type of circuit is normally internal to an organisation to interconnect groups both globally and regionally. In future, newer Private Wire networks will be able to offer this type of service between organisations. Once the 'pw-type' parameter is set in the initial INVITE request it MUST not be changed for the duration of the SIP INVITE dialog. An entity receiving a request with a 'pw-type' parameter that is not supported MUST respond with a SIP 4XX response. An entity receiving a reliable SIP response that contains a 'pw-type' parameter that is not supported MUST terminate the SIP dialog as immediately as per RFC 3261 [RFC3261]. An entity receiving a SIP INFO message containing an incorrect element associated with the 'pw-type' MUST respond with a SIP 4XX response and ensure the associated SIP INVITE dialog is terminated. -- The document date (December 2, 2016) is 2702 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3023' is mentioned on line 725, but not defined ** Obsolete undefined reference: RFC 3023 (Obsoleted by RFC 7303) == Unused Reference: 'RFC3326' is defined on line 782, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2833 (Obsoleted by RFC 4733, RFC 4734) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Fraser 3 Internet-Draft BT Trading Systems 4 Intended status: Informational C. Boulton 5 Expires: June 5, 2017 R. Beauchamp 6 Dialogic 7 December 2, 2016 9 A Session Initiation Protocol (SIP) INFO package for Private Wire 10 draft-beauchamp-private-wire-10 12 Abstract 14 Application level data exchanged using the SIP INFO method are 15 supported and documented in specifications known as 'INFO Packages'. 16 This document defines functionality associated with Session 17 Initiation Protocol (SIP) Private Wire functionality and creates an 18 'INFO Package' for carrying such application level data. 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 June 5, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 56 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Overlapping Requests . . . . . . . . . . . . . . . . . . 6 58 3.2. Incorrect Private Wire Type . . . . . . . . . . . . . . . 7 59 4. Private Wire Package Definition . . . . . . . . . . . . . . . 7 60 4.1. Overall Description . . . . . . . . . . . . . . . . . . . 7 61 4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. INFO Package Name . . . . . . . . . . . . . . . . . . . . 7 63 4.4. INFO Package Parameters . . . . . . . . . . . . . . . . . 7 64 4.5. SIP OPTION tags . . . . . . . . . . . . . . . . . . . . . 8 65 4.6. INFO Message Body Parts . . . . . . . . . . . . . . . . . 8 66 5. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1.1. . . . . . . . . . . . . . . . . . . . . . 9 69 5.1.2. . . . . . . . . . . . . . . . . . . . . 9 70 6. 'pwtype' INFO Package Parameter . . . . . . . . . . . . . . . 9 71 7. SIP OPTIONS Tag . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. Example Exchange . . . . . . . . . . . . . . . . . . . . . . 10 73 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 74 10. Legacy Interoperation . . . . . . . . . . . . . . . . . . . . 16 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 12.1. application/pw-info+xml MIME type . . . . . . . . . . . 16 78 12.2. pw-info-package SIP OPTIONS tag . . . . . . . . . . . . 17 79 13. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 17 80 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 15. Normative References . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 Private Wire (PW) is a generic term used to describe static point to 87 point voice connections between two locations. Private Wires are 88 used by a number of communities such as Military, Railways, 911/999 89 Services and Financial Services. This document will primarily deal 90 with the Financial Services Industry however it should be equally 91 applicable to other communities. 93 The aim is to define a SIP based emulation of existing Private Wire 94 circuits so that interoperability can be attained between existing 95 digital and analogue equipment and the new generation of SIP based 96 technology. 98 This document does not seek to add functionality above the existing 99 Private Wire experience or to define new financial services that may 100 be possible using SIP interconnections between trading systems. 102 Financial Institutions are traditional early adopters of 103 telecommunications technology. The phone became so important that 104 any loss of service could result in huge losses in the markets. 105 Traders and brokers in particular were quick to realise some of the 106 short comings of PSTN interconnection when used for voice trading, 107 such as:- 109 o Slow speed of dialling especially with rotary dials. 111 o Slow speed of connection which could lead to missing first part of 112 conversation. 114 o No ability for their calls to be given high priority in the PSTN 115 so calls would not get through. 117 o Far end was on a call to someone else and so would not answer. 119 To solve these issues the financial communities took advantage of the 120 fact that their offices in any given location were very close to all 121 the offices of their trading partners and started to run direct 122 private connections between themselves. 124 It is the intention of this document to create SIP based Private Wire 125 functionality that will enable new systems to provide equivalent 126 functionality in an interoperable form. This includes interoperation 127 with legacy systems. 129 A SIP based solution uses core SIP functionality to enable a device 130 compliant to this specification to signal information specifically 131 related to a Private Wire. In its most simplistic form the SIP 132 signalling, as illustrated in Figure 1, representing a Private Wire 133 is re-used with extensions defined in this specification which 134 imitates legacy functionality (intermediaries left out for 135 simplicity). 137 +-------SIP Traffic (Private Wire)------+ 138 | | 139 v v 140 +--+--+ +--+--+ 141 | SIP | | SIP | 142 |Stack| |Stack| 143 +---+-----+---+ +---+-----+---+ 144 | | | | 145 | Trading | | Trading | 146 | Desk | | Desk | 147 | |<----------RTP---------->| | 148 +-------------+ +-------------+ 150 Figure 1: SIP Private Wire 152 While it is envisioned that all existing deployments will move to a 153 SIP based solution it must be recognised that the majority of 154 deployments using this specification will be interacting with legacy 155 Private Wire systems for the foreseeable future, as illustrated in 156 Figure 2. 158 +----------SIP Traffic----------+ 159 | | 160 v v 161 +-----+ +--+--+ 162 | SIP | | SIP | 163 |Stack| |Stack| 164 +---+-----+---+ +---+-----+---+ 165 | | | | 166 ====================| Network | | Trading | 167 Legacy Private Wire | Gateway | | Desk | 168 ====================| |<------RTP------>| | 169 +-------------+ +-------------+ 171 Figure 2: Legacy Private Wire 173 This specification will define a Session Initiation Protocol (SIP) 174 INFO package, as defined in [RFC6086], for the purpose of mid call 175 signalling related to Private Wire functionality. The remainder of 176 this specification will define the appropriate level of detail from 177 both a functional and standardisation perspective. 179 2. Conventions and Terminology 181 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words 182 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 183 "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL". In addition, BCP 15 indicates requirement levels for 185 compliant implementations. 187 The following additional terms are defined for use in this document: 189 Private Wire (PW) : generic term used to describe static point to 190 point communication connections between two locations. 192 3. Overview of Operation 194 The use of Session Initiation Protocol (SIP) for Private Wire 195 communication allows for migration of existing functionality and 196 deployments. It also provides an appropriate foundation for future 197 extensions to enhance Private Wire functionality. 199 A SIP Private Wire will make use of existing SIP standards as well as 200 the extensions defined in this document - as covered in the remainder 201 of this section. 203 A SIP based Private Wire will be established as any other INVITE 204 dialog specified in RFC 3261 [RFC3261] with the following additional 205 steps: 207 o On constructing the initial INVITE request the User Agent Client 208 (UAC) MUST include a SIP 'Recv-info' header (as defined in 209 [RFC6086] with a value of 'pw-info-package'. The 'pw-type' 210 parameter MUST also be included with an appropriate value. 212 o On constructing a reliable response (as defined in [RFC3261]) to 213 the INVITE request the SIP 'Recv-info' header MUST be included 214 with a value of 'pw-info-package'. The 'pw-type' parameter MUST 215 also be included with an appropriate value. An entity receiving a 216 SIP INVITE request/response MUST NOT issue commands for this INFO 217 package if the SIP 'Recv-info' header is not present. 219 o All SIP INFO messages defined in this package for Private Wire 220 signalling MUST contain the SIP 'Info-Package' header with a value 221 of 'pw-info-package'. 223 A SIP entity that receives a Private Wire SIP INVITE request for a 224 domain that it controls (appears in the host part of the SIP URI) but 225 does not recognise the user part MUST issue a SIP 404 response if no 226 other routing path is defined. A SIP entity that receives a Private 227 Wire SIP INVITE request for a domain that it controls (appears in the 228 host part of the SIP URI) but has definitive knowledge that the 229 Private Wire is out of service, MUST issue a SIP 480 response. 230 Overlapping SIP INVITE transactions MUST be treated as per described 231 in Section 3.1. 233 The INVITE dialog establishing a SIP Private Wire MUST comply to 234 appropriate security procedures as set out in Section 4. A SIP 235 Private Wire SHOULD use TCP as the signalling protocol but MAY choose 236 to use an alternative transport protocol if appropriate. 238 A SIP endpoint configured to initiate a SIP Private Wire MUST also 239 support the 'Session Timer' extension as specified in RFC 4028 240 [RFC4028]. It is important that a SIP Private Wire is always 241 available and so early detection of failure is important to the 242 service. A SIP endpoint initiating a SIP Private wire should pick a 243 refresh interval in association with [RFC4028] that is suitable for 244 the system. A refresh interval of 120 seconds is RECOMMENDED. On 245 detection of failure, a SIP endpoint MUST attempt to re-establish the 246 SIP Private Wire immediately. 248 While an active SIP based Private Wire is established, a user may 249 wish to signal certain events to the far end of the SIP INVITE 250 dialog. To achieve the SIP INFO method is used in association with 251 the INFO Package defined in this specification. More specifically, 252 an endpoint wishing to signal Private Wire related information to the 253 receiving end MUST comply to the SIP INFO package specification 254 defined in Section 4. This primarily involves the ability to: 256 o Signal 'On Hook' and 'Off Hook' state. 258 o Signal 'Ringdown' state (play locally configured alert). 260 o Provide Transmission Only Service(TOS) Private Wire. 262 A SIP endpoint not compliant to this specification can still 263 successfully interoperate with a compliant device but will not be 264 able to take advantage of the specific Private Wire functionality 265 defined in this document. 267 3.1. Overlapping Requests 269 In the event that two endpoints actively attempting to connect a 270 Private Wire call at the same time, an endpoint should be able to 271 detect and resolve this situation. On receiving an incoming request 272 to a well known Private Wire identifier the endpoint MUST check to 273 see if it has an active INVITE transaction for the same Private Wire. 274 If the endpoint does have an active INVITE transaction it MUST: 276 o Generate a SIP 486 Busy Here response to the incoming INVITE 277 transaction associated with the Private Wire. 279 o Include a SIP 'Retry-After' header[RFC3261] in the 486 with an 280 appropriate value which should reflect a point in the future when 281 a new attempt might succeed. As a guideline this figure should be 282 greater than the remaining amount of time left for the current 283 outgoing Private Wire INVITE transaction. 285 o Include a SIP Reason header[RFC3261] in the 486 with the value 286 'Reason: SIP;cause=486;text="Overlapping PW Establishment"'. 288 3.2. Incorrect Private Wire Type 290 A SIP INVITE compliant to this specification MUST include a 'Recv- 291 Info' header, as defined further in Section 6. An endpoint receiving 292 a 'Recv-Info' header with a value that is not supported should 293 respond with a SIP '469 Bad Info Package', as defined in [RFC6086]. 295 4. Private Wire Package Definition 297 4.1. Overall Description 299 An Overall Description of the Private Wire INFO package can be found 300 in Section 3. 302 4.2. Applicability 304 The SIP INFO package mechanism was chosen for the purpose of carrying 305 Private Wire application level information as it offered the most 306 appropriate solution. Using a SIP INFO package encourages signalling 307 to be viewed by appropriate intermediaries in Trading System 308 architectures. 310 4.3. INFO Package Name 312 This document defines a SIP INFO Package as defined in [RFC6086]. 313 The INFO Package token name for this package is "pw-info-package". 315 4.4. INFO Package Parameters 317 This document defines a single INFO package parameter. See Section 6 318 for the definition of the 'pwtype' INFO package parameter. 320 4.5. SIP OPTION tags 322 See Section 7. 324 4.6. INFO Message Body Parts 326 A client conforming to this specification MUST include a compliant 327 payload in a SIP INFO message that conforms to the XML schema defined 328 in Section 9. The MIME type MUST be of type 'application/pw- 329 info+xml' as defined in Section 12.1. 331 5. Element Definitions 333 This section defines the XML elements for this package. The elements 334 are defined in the XML namespace specified in Section 9. 336 The root element is . All other elements are contained 337 within it. Child elements are and . The 338 element is described in Section 5.1.1. The 339 element is described in Section 5.1.2. 341 Implementations of this specification MUST address the Security 342 Considerations described in Section 11. Implementations of this 343 specification MUST adhere to the syntax and semantics defined in this 344 section and the schema in Section 9. If there is a difference in 345 constraints between the XML schema and the textual description of 346 elements in this section, the textual definition takes priority. 348 The XML schema supports extensibility by allowing attributes and 349 elements from other namespaces. Implementations MAY support 350 additional capabilities by means of attributes and elements from 351 other (foreign) namespaces. Attributes and elements from foreign 352 namespaces are not described in this section. 354 5.1. 356 The element has no attributes in addition to the standard 357 XML namespace attributes such as xmlns. 359 The element has two child elements of which only one can 360 occur per message.: 362 o - defined in Section 5.1.1. 364 o - defined in Section 5.1.2. 366 5.1.1. 368 The element is used to request a local 'ringdown' alert at 369 the remote party of the private wire. 371 The element has the following attributes: 373 o signal: conveys an alert on the associated private wire. Contains 374 a single value of 'ring' or 'noring'. The value 'ring' informs 375 the remote client to alert the user based on a locally defined 376 ring cadence and duration. The value 'noring' informs the remote 377 client to cease alerting the user's locally defined ring cadence. 379 The element has no child elements. 381 5.1.2. 383 The element is used to convey a 'hookSwitch' alert to 384 the remote party of the private wire. 386 The element has the following attributes: 388 o signal: conveys the state of the associated private wire. Values 389 can either be 'onHook' or 'offHook'. The value 'onHook' to signal 390 'not in use' on a private wire. The value 'offHook' to signal 'in 391 use' on a private wire. 393 The element has no child elements. 395 6. 'pwtype' INFO Package Parameter 397 The Info package specification allows individual packages to define 398 parameters for the 'Recv-Info' and 'Info-Package' header. This 399 document defines one new event package parameter: pw-type. 401 A single instance of the 'pw-type' parameter MUST be included with a 402 'Recv-Info' header to convey the type of private wire being used for 403 the SIP dialog. The value of 'pw-type' can either be 'ringdown', 404 'hookswitch' or 'TOS'. By specifying a value of 'ringdown' in the 405 'pw-type' parameter the element MUST be used from 406 Section 9. By specifying a value of 'hookswitch' in the 'pw-type' 407 parameter the element MUST be used from Section 9. By 408 specifying 'TOS'(Transmission Only Service) no additional signalling 409 is used in complying with this specification (future specifications 410 may provide additional functionality). TOS is normally used for 411 interconnecting voice systems that need no signalling and are always 412 assumed to be connected. An example might be TV audio or a Hoot 413 line. This type of circuit is normally internal to an organisation 414 to interconnect groups both globally and regionally. In future, 415 newer Private Wire networks will be able to offer this type of 416 service between organisations. Once the 'pw-type' parameter is set 417 in the initial INVITE request it MUST not be changed for the duration 418 of the SIP INVITE dialog. An entity receiving a request with a 'pw- 419 type' parameter that is not supported MUST respond with a SIP 4XX 420 response. An entity receiving a reliable SIP response that contains 421 a 'pw-type' parameter that is not supported MUST terminate the SIP 422 dialog as immediately as per RFC 3261 [RFC3261]. An entity receiving 423 a SIP INFO message containing an incorrect element associated with 424 the 'pw-type' MUST respond with a SIP 4XX response and ensure the 425 associated SIP INVITE dialog is terminated. 427 The ABNF for the 'pw-type' parameter is shown below. 429 pw-type = "pw-type" EQUAL pwtype 430 pwtype = "ringdown" / "hookswitch" / "TOS" 432 Figure 3 434 7. SIP OPTIONS Tag 436 The Info package specification allows individual packages to define a 437 SIP OPTIONS tag to enable discovery of support for this 438 specification. 440 SIP entities generating an offer or answer that uses the Private Wire 441 INFO package MUST place the 'pw-info-package' option-tag in a SIP 442 Supported header field. When responding to, or generating a SIP 443 OPTIONS request a SIP entity MUST include the 'pw-info-package' in a 444 SIP Supported header field. SIP entities that support the Private 445 Wire INFO package MUST understand the 'pw-info-package' option-tag. 447 8. Example Exchange 449 The following example provides a simple exchange between a Network 450 Gateway (NWG) and a SIP based Trading Desk. 452 Trading 453 NWG Desk 454 | | 455 |(1) INVITE | 456 |------------------------->| 457 | | 458 |(2) 200 OK | 459 |<-------------------------| 460 | | 461 |(3) ACK | 462 |------------------------->| 463 | | 464 |**************************| 465 | Private Wire Established | 466 |**************************| 467 | | 468 |(4) INFO | 469 |------------------------->| 470 | | 471 |(5) 200 OK | 472 |<-------------------------| 473 | | 474 |(6) INFO | 475 |------------------------->| 476 | | 477 |(7) 200 OK | 478 |<-------------------------| 479 | | 481 Figure 4 483 The example in this section represents an interaction between a 484 Network Gateway (NWG) and a SIP enabled Trading desk. The remainder 485 of this section provides more detail relating to Figure 4. Some 486 detail has been left out for simplicity. 488 The NWG sends an initial INVITE (1) request. The INVITE request 489 indicates that it is willing to receive SIP INFO requests for the 490 Private Wire package. 492 INVITE sip:pw@example.com SIP/2.0 493 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK1 494 Max-Forwards: 70 495 To: PW 496 From: Bank ;tag=100 497 Call-ID: abcd1234@pc1.example.com 498 CSeq: 1 INVITE 499 Supported: pw-info-package 500 Recv-Info: pw-info-package;pw-type=hookswitch 501 Contact: 502 Content-Type: application/sdp 503 Content-Length: ... 505 ... 507 The Trading Desk responds with a 200 OK(2) response. The 200 OK 508 response indicates that it is willing to receive SIP INFO requests 509 for the Private Wire package. 511 SIP/2.0 200 OK 512 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK1;received=192.0.2.1 513 To: PW ;tag=200 514 From: Bank ;tag=100 515 Call-ID: abcd1234@pc1.example.com 516 CSeq: 1 INVITE 517 Contact: 518 Supported: pw-info-package 519 Recv-Info: pw-info-package;pw-type=hookswitch 520 Content-Type: application/sdp 521 Content-Length: ... 523 ... 525 The NWG sends an ACK(3) request to complete the INVITE transaction. 527 ACK sip:trader@pc2.example.com SIP/2.0 528 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK2 529 Max-Forwards: 70 530 To: Bob ;tag=200 531 From: Alice ;tag=100 532 Call-ID: abcd1234@pc1.example.com 533 CSeq: 1 ACK 534 Content-Length: 0 536 The NWG sends an INFO(4) request. The INFO request contains a 'pw' 537 package payload signalling 'off hook'. 539 INFO sip:trader@pc2.example.com SIP/2.0 540 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK3 541 Max-Forwards: 70 542 To: Bob ;tag=200 543 From: Alice ;tag=100 544 Call-ID: abcd1234@pc1.example.com 545 CSeq: 2 INFO 546 Info-Package: pw-info-package 547 Content-type: application/pw-info+xml 548 Content-Disposition: Info-Package 549 Content-Length: 109 551 552 553 555 The Trading Desk sends a 200 OK(5) request. 557 SIP/2.0 200 OK 558 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK3 559 Max-Forwards: 70 560 To: Bob ;tag=200 561 From: Alice ;tag=100 562 Call-ID:abcd1234@pc1.example.com 563 CSeq: 2 INFO 564 Content-Length: 0 566 The NWG sends an INFO(6) request. The INFO request contains a 'pw' 567 package payload signalling 'on hook'. 569 INFO sip:trader@pc2.example.com SIP/2.0 570 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK4 571 Max-Forwards: 70 572 To: Bob ;tag=200 573 From: Alice ;tag=100 574 Call-ID:abcd1234@pc1.example.com 575 CSeq: 3 INFO 576 Info-Package: pw-info-package 577 Content-type: application/pw-info+xml 578 Content-Disposition: Info-Package 579 Content-Length: 108 581 582 583 585 The Trading Desk sends a 200 OK(7) request. 587 SIP/2.0 200 OK 588 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK4 589 Max-Forwards: 70 590 To: Bob ;tag=200 591 From: Alice ;tag=100 592 Call-ID: abcd1234@pc1.example.com 593 CSeq: 3 INFO 594 Content-Length: 0 596 9. Formal Syntax 598 599 605 606 Version 0.1 Draft XML schema 607 for Private Wire Signalling in SIP INFO body 608 609 611 619 621 622 623 624 625 626 628 629 630 632 634 636 638 639 640 642 643 645 646 648 650 652 653 654 656 657 659 660 662 664 673 674 675 676 677 678 679 680 681 682 683 684 686 688 10. Legacy Interoperation 690 The existing install base of PW are made up of E1/T1 CAS or analogue 691 circuits and in order to interoperate with the legacy equipment a 692 gateway function is required. There are a number of different 693 signalling types in use and it will be the job of the gateway to map 694 the legacy signalling to the proposed SIP INFO messages. 696 A number of gateways that exist have solved this problem using RFC 697 2833 [RFC2833] which allows call events on trunks to be sent in the 698 media plane as RTP packets. Gateway devices or Session Border 699 Controller (SBC) devices implementing this new SIP based signalling 700 should to be able to inter operate with this standard and to be able 701 to translate between the two worlds. 703 11. Security Considerations 705 Security Considerations to be included in later versions of this 706 document. 708 12. IANA Considerations 710 12.1. application/pw-info+xml MIME type 712 This section registers the "application/pw-info+xml" MIME type. 714 To: ietf-types@iana.org 715 Subject: Registration of MIME media type 716 application/pw-info+xml 717 MIME media type name: application 718 MIME subtype name: pw-info+xml 719 Required parameters: (none) 720 Optional parameters: charset 721 Indicates the character encoding of enclosed XML. Default is 722 UTF-8. 723 Encoding considerations: Uses XML, which can employ 8-bit 724 characters, depending on the character encoding used. See RFC 725 3023 [RFC3023], section 3.2. 726 Security considerations: No known security considerations outside 727 of those provided by the Private Wire SIP INFO Package. 728 Interoperability considerations: This content type provides 729 constructs for the Private Wire SIP INFO Package. 730 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 731 replace XXXX with the RFC number for this specification.] 732 Applications which use this media type: Implementations of 733 the Private Wire SIP INFO package. 734 Additional Information: Magic Number(s): (none) 735 File extension(s): (none) 736 Macintosh File Type Code(s): (none) 737 Person & email address to contact for further information: Chris 738 Boulton 739 Intended usage: LIMITED USE 740 Author/Change controller: The IETF 741 Other information: None. 743 12.2. pw-info-package SIP OPTIONS tag 745 This section defines a new SIP option tag per the guidelines in 746 Section 27.1 of RFC 3261 [RFC3261]. 748 Name: pw-info-package 750 Description: This option tag is used to identify the Private 751 Wire INFO package extension. When present in a 752 Require header field, it indicates that Private Wire is 753 required by a receiving client. 755 13. Change Summary 757 This section will document changes made in future versions. 759 14. Acknowledgements 761 The authors would like to thank John Stafford and David Cohen of BT 762 for their input. 764 15. Normative References 766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 767 Requirement Levels", BCP 14, RFC 2119, 768 DOI 10.17487/RFC2119, March 1997, 769 . 771 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 772 Digits, Telephony Tones and Telephony Signals", RFC 2833, 773 DOI 10.17487/RFC2833, May 2000, 774 . 776 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 777 A., Peterson, J., Sparks, R., Handley, M., and E. 778 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 779 DOI 10.17487/RFC3261, June 2002, 780 . 782 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 783 Header Field for the Session Initiation Protocol (SIP)", 784 RFC 3326, DOI 10.17487/RFC3326, December 2002, 785 . 787 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 788 Session Initiation Protocol (SIP)", RFC 4028, 789 DOI 10.17487/RFC4028, April 2005, 790 . 792 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 793 Initiation Protocol (SIP) INFO Method and Package 794 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 795 . 797 Authors' Addresses 799 Finlay Fraser 800 BT Trading Systems 802 Email: finlay.fraser_AT_bt.com 804 Chris Boulton 805 Dialogic 806 Richard Beauchamp 807 Dialogic