Network Working Group R. Beauchamp Internet-Draft Unaffiliated Intended status: Informational F. Fraser Expires: January 31, 2014 BT Trading Systems C. Boulton NS-Technologies July 30, 2013 A Session Initiation Protocol (SIP) INFO package for Private Wire draft-beauchamp-private-wire-07 Abstract Application level data exchanged using the SIP INFO method are supported and documented in specifications known as 'INFO Packages'. This document defines functionality associated with Session Initiation Protocol (SIP) Private Wire functionality and creates an 'INFO Package' for carrying such application level data. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 31, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Beauchamp, et al. Expires January 31, 2014 [Page 1] Internet-Draft SIP INFO Package for Private Wire July 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 3.1. Overlapping Requests . . . . . . . . . . . . . . . . . . 6 3.2. Incorrect Private Wire Type . . . . . . . . . . . . . . . 7 4. Private Wire Package Definition . . . . . . . . . . . . . . . 7 4.1. Overall Description . . . . . . . . . . . . . . . . . . . 7 4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 4.3. INFO Package Name . . . . . . . . . . . . . . . . . . . . 7 4.4. INFO Package Parameters . . . . . . . . . . . . . . . . . 7 4.5. SIP OPTION tags . . . . . . . . . . . . . . . . . . . . . 7 4.6. INFO Message Body Parts . . . . . . . . . . . . . . . . . 8 5. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8 5.1. . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. . . . . . . . . . . . . . . . . . . . . 9 6. 'pwtype' INFO Package Parameter . . . . . . . . . . . . . . . 9 7. SIP OPTIONS Tag . . . . . . . . . . . . . . . . . . . . . . . 10 8. Example Exchange . . . . . . . . . . . . . . . . . . . . . . 10 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Legacy Interoperation . . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12.1. application/pw-info+xml MIME type . . . . . . . . . . . 16 12.2. pw-info-package SIP OPTIONS tag . . . . . . . . . . . . 17 13. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 17 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 15. Normative References . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Private Wire (PW) is a generic term used to describe static point to point voice connections between two locations. Private Wires are used by a number of communities such as Military, Railways, 911/999 Services and Financial Services. This document will primarily deal with the Financial Services Industry however it should be equally applicable to other communities. Beauchamp, et al. Expires January 31, 2014 [Page 2] Internet-Draft SIP INFO Package for Private Wire July 2013 The aim is to define a SIP based emulation of existing Private Wire circuits so that interoperability can be attained between existing digital and analogue equipment and the new generation of SIP based technology. This document does not seek to add functionality above the existing Private Wire experience or to define new financial services that may be possible using SIP interconnections between trading systems. Financial Institutions are traditional early adopters of telecommunications technology. The phone became so important that any loss of service could result in huge losses in the markets. Traders and brokers in particular were quick to realise some of the short comings of PSTN interconnection when used for voice trading, such as:- o Slow speed of dialling especially with rotary dials. o Slow speed of connection which could lead to missing first part of conversation. o No ability for their calls to be given high priority in the PSTN so calls would not get through. o Far end was on a call to someone else and so would not answer. To solve these issues the financial communities took advantage of the fact that their offices in any given location were very close to all the offices of their trading partners and started to run direct private connections between themselves. It is the intention of this document to create SIP based Private Wire functionality that will enable new systems to provide equivalent functionality in an interoperable form. This includes interoperation with legacy systems. A SIP based solution uses core SIP functionality to enable a device compliant to this specification to signal information specifically related to a Private Wire. In its most simplistic form the SIP signalling, as illustrated in Figure 1, representing a Private Wire is re-used with extensions defined in this specification which imitates legacy functionality (intermediaries left out for simplicity). +-------SIP Traffic (Private Wire)------+ | | v v Beauchamp, et al. Expires January 31, 2014 [Page 3] Internet-Draft SIP INFO Package for Private Wire July 2013 +--+--+ +--+--+ | SIP | | SIP | |Stack| |Stack| +---+-----+---+ +---+-----+---+ | | | | | Trading | | Trading | | Desk | | Desk | | |<----------RTP---------->| | +-------------+ +-------------+ Figure 1: SIP Private Wire While it is envisioned that all existing deployments will move to a SIP based solution it must be recognised that the majority of deployments using this specification will be interacting with legacy Private Wire systems for the foreseeable future, as illustrated in Figure 2. +----------SIP Traffic----------+ | | v v +-----+ +--+--+ | SIP | | SIP | |Stack| |Stack| +---+-----+---+ +---+-----+---+ | | | | ====================| Network | | Trading | Legacy Private Wire | Gateway | | Desk | ====================| |<------RTP------>| | +-------------+ +-------------+ Figure 2: Legacy Private Wire This specification will define a Session Initiation Protocol (SIP) INFO package, as defined in [RFC6086], for the purpose of mid call signalling related to Private Wire functionality. The remainder of this specification will define the appropriate level of detail from both a functional and standardisation perspective. 2. Conventions and Terminology Beauchamp, et al. Expires January 31, 2014 [Page 4] Internet-Draft SIP INFO Package for Private Wire July 2013 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In addition, BCP 15 indicates requirement levels for compliant implementations. The following additional terms are defined for use in this document: Private Wire (PW) : generic term used to describe static point to point communication connections between two locations. 3. Overview of Operation The use of Session Initiation Protocol (SIP) for Private Wire communication allows for migration of existing functionality and deployments. It also provides an appropriate foundation for future extensions to enhance Private Wire functionality. A SIP Private Wire will make use of existing SIP standards as well as the extensions defined in this document - as covered in the remainder of this section. A SIP based Private Wire will be established as any other INVITE dialog specified in RFC 3261 [RFC3261] with the following additional steps: o On constructing the initial INVITE request the User Agent Client (UAC) MUST include a SIP 'Recv-info' header (as defined in [RFC6086] with a value of 'pw-info-package'. The 'pw-type' parameter MUST also be included with an appropriate value. o On constructing a reliable response (as defined in [RFC3261]) to the INVITE request the SIP 'Recv-info' header MUST be included with a value of 'pw-info-package'. The 'pw-type' parameter MUST also be included with an appropriate value. An entity receiving a SIP INVITE request/response MUST NOT issue commands for this INFO package if the SIP 'Recv-info' header is not present. o All SIP INFO messages defined in this package for Private Wire signalling MUST contain the SIP 'Info-Package' header with a value of 'pw-info-package'. A SIP entity that receives a Private Wire SIP INVITE request for a domain that it controls (appears in the host part of the SIP URI) but does not recognise the user part MUST issue a SIP 404 response if no other routing path is defined. A SIP entity that receives a Private Wire SIP INVITE request for a domain that it controls (appears in the host part of the SIP URI) but has definitive knowledge that the Beauchamp, et al. Expires January 31, 2014 [Page 5] Internet-Draft SIP INFO Package for Private Wire July 2013 Private Wire is out of service, MUST issue a SIP 480 response. Overlapping SIP INVITE transactions MUST be treated as per described in Section 3.1. The INVITE dialog establishing a SIP Private Wire MUST comply to appropriate security procedures as set out in Section 4. A SIP Private Wire SHOULD use TCP as the signalling protocol but MAY choose to use an alternative transport protocol if appropriate. A SIP endpoint configured to initiate a SIP Private Wire MUST also support the 'Session Timer' extension as specified in RFC 4028 [RFC4028]. It is important that a SIP Private Wire is always available and so early detection of failure is important to the service. A SIP endpoint initiating a SIP Private wire should pick a refresh interval in association with [RFC4028] that is suitable for the system. A refresh interval of 120 seconds is RECOMMENDED. On detection of failure, a SIP endpoint MUST attempt to re-establish the SIP Private Wire immediately. While an active SIP based Private Wire is established, a user may wish to signal certain events to the far end of the SIP INVITE dialog. To achieve the SIP INFO method is used in association with the INFO Package defined in this specification. More specifically, an endpoint wishing to signal Private Wire related information to the receiving end MUST comply to the SIP INFO package specification defined in Section 4. This primarily involves the ability to: o Signal 'On Hook' and 'Off Hook' state. o Signal 'Ringdown' state (play locally configured alert). o Provide Transmission Only Service(TOS) Private Wire. A SIP endpoint not compliant to this specification can still successfully interoperate with a compliant device but will not be able to take advantage of the specific Private Wire functionality defined in this document. 3.1. Overlapping Requests In the event that two endpoints actively attempting to connect a Private Wire call at the same time, an endpoint should be able to detect and resolve this situation. On receiving an incoming request to a well known Private Wire identifier the endpoint MUST check to see if it has an active INVITE transaction for the same Private Wire. If the endpoint does have an active INVITE transaction it MUST: Beauchamp, et al. Expires January 31, 2014 [Page 6] Internet-Draft SIP INFO Package for Private Wire July 2013 o Generate a SIP 486 Busy Here response to the incoming INVITE transaction associated with the Private Wire. o Include a SIP 'Retry-After' header[RFC3261] in the 486 with an appropriate value which should reflect a point in the future when a new attempt might succeed. As a guideline this figure should be greater than the remaining amount of time left for the current outgoing Private Wire INVITE transaction. o Include a SIP Reason header[RFC3261] in the 486 with the value 'Reason: SIP;cause=486;text="Overlapping PW Establishment"'. 3.2. Incorrect Private Wire Type A SIP INVITE compliant to this specification MUST include a 'Recv- Info' header, as defined further in Section 6. An endpoint receiving a 'Recv-Info' header with a value that is not supported should respond with a SIP '469 Bad Info Package', as defined in [RFC6086]. 4. Private Wire Package Definition 4.1. Overall Description An Overall Description of the Private Wire INFO package can be found in Section 3. 4.2. Applicability The SIP INFO package mechanism was chosen for the purpose of carrying Private Wire application level information as it offered the most appropriate solution. Using a SIP INFO package encourages signalling to be viewed by appropriate intermediaries in Trading System architectures. 4.3. INFO Package Name This document defines a SIP INFO Package as defined in [RFC6086]. The INFO Package token name for this package is "pw-info-package". 4.4. INFO Package Parameters This document defines a single INFO package parameter. See Section 6 for the definition of the 'pwtype' INFO package parameter. 4.5. SIP OPTION tags See Section 7. Beauchamp, et al. Expires January 31, 2014 [Page 7] Internet-Draft SIP INFO Package for Private Wire July 2013 4.6. INFO Message Body Parts A client conforming to this specification MUST include a compliant payload in a SIP INFO message that conforms to the XML schema defined in Section 9. The MIME type MUST be of type 'application/pw- info+xml' as defined in Section 12.1. 5. Element Definitions This section defines the XML elements for this package. The elements are defined in the XML namespace specified in Section 9. The root element is . All other elements are contained within it. Child elements are and . The element is described in Section 5.1.1. The element is described in Section 5.1.2. Implementations of this specification MUST address the Security Considerations described in Section 11. Implementations of this specification MUST adhere to the syntax and semantics defined in this section and the schema in Section 9. If there is a difference in constraints between the XML schema and the textual description of elements in this section, the textual definition takes priority. The XML schema supports extensibility by allowing attributes and elements from other namespaces. Implementations MAY support additional capabilities by means of attributes and elements from other (foreign) namespaces. Attributes and elements from foreign namespaces are not described in this section. 5.1. The element has no attributes in addition to the standard XML namespace attributes such as xmlns. The element has two child elements of which only one can occur per message.: o - defined in Section 5.1.1. o - defined in Section 5.1.2. 5.1.1. The element is used to request a local 'ringdown' alert at the remote party of the private wire. The element has the following attributes: Beauchamp, et al. Expires January 31, 2014 [Page 8] Internet-Draft SIP INFO Package for Private Wire July 2013 o signal: conveys an alert on the associated private wire. Contains a single value of 'ring'. The value 'ring' informs the remote client to alert the user based on a locally defined ring cadence and duration. NOTE: There is no signal to signify the end of ringing, this is a characteristic to be defined by the remote system The element has no child elements. 5.1.2. The element is used to convey a 'hookSwitch' alert to the remote party of the private wire. The element has the following attributes: o signal: conveys the state of the associated private wire. Values can either be 'onHook' or 'offHook'. The value 'onHook' to signal 'not in use' on a private wire. The value 'offHook' to signal 'in use' on a private wire. The element has no child elements. 6. 'pwtype' INFO Package Parameter The Info package specification allows individual packages to define parameters for the 'Recv-Info' and 'Info-Package' header. This document defines one new event package parameter: pw-type. 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 Beauchamp, et al. Expires January 31, 2014 [Page 9] Internet-Draft SIP INFO Package for Private Wire July 2013 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 ABNF for the 'pw-type' parameter is shown below. pw-type = "pw-type" EQUAL pwtype pwtype = "ringdown" / "hookswitch" / "TOS" Figure 3 7. SIP OPTIONS Tag The Info package specification allows individual packages to define a SIP OPTIONS tag to enable discovery of support for this specification. SIP entities generating an offer or answer that uses the Private Wire INFO package MUST place the 'pw-info-package' option-tag in a SIP Supported header field. When responding to, or generating a SIP OPTIONS request a SIP entity MUST include the 'pw-info-package' in a SIP Supported header field. SIP entities that support the Private Wire INFO package MUST understand the 'pw-info-package' option-tag. 8. Example Exchange The following example provides a simple exchange between a Network Gateway (NWG) and a SIP based Trading Desk. Trading NWG Desk | | |(1) INVITE | |------------------------->| | | |(2) 200 OK | |<-------------------------| | | |(3) ACK | |------------------------->| | | |**************************| | Private Wire Established | |**************************| | | Beauchamp, et al. Expires January 31, 2014 [Page 10] Internet-Draft SIP INFO Package for Private Wire July 2013 |(4) INFO | |------------------------->| | | |(5) 200 OK | |<-------------------------| | | |(6) INFO | |------------------------->| | | |(7) 200 OK | |<-------------------------| | | Figure 4 The example in this section represents an interaction between a Network Gateway (NWG) and a SIP enabled Trading desk. The remainder of this section provides more detail relating to Figure 4. Some detail has been left out for simplicity. The NWG sends an initial INVITE (1) request. The INVITE request indicates that it is willing to receive SIP INFO requests for the Private Wire package. INVITE sip:pw@example.com SIP/2.0 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK1 Max-Forwards: 70 To: PW From: Bank ;tag=100 Call-ID: abcd1234@pc1.example.com CSeq: 1 INVITE Supported: pw-info-package Recv-Info: pw-info-package;pw-type=hookswitch Contact: Content-Type: application/sdp Content-Length: ... ... The Trading Desk responds with a 200 OK(2) response. The 200 OK response indicates that it is willing to receive SIP INFO requests for the Private Wire package. SIP/2.0 200 OK Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK1;received=192.0.2.1 Beauchamp, et al. Expires January 31, 2014 [Page 11] Internet-Draft SIP INFO Package for Private Wire July 2013 To: PW ;tag=200 From: Bank ;tag=100 Call-ID: abcd1234@pc1.example.com CSeq: 1 INVITE Contact: Supported: pw-info-package Recv-Info: pw-info-package;pw-type=hookswitch Content-Type: application/sdp Content-Length: ... ... The NWG sends an ACK(3) request to complete the INVITE transaction. ACK sip:trader@pc2.example.com SIP/2.0 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK2 Max-Forwards: 70 To: Bob ;tag=200 From: Alice ;tag=100 Call-ID: abcd1234@pc1.example.com CSeq: 1 ACK Content-Length: 0 The NWG sends an INFO(4) request. The INFO request contains a 'pw' package payload signalling 'off hook'. INFO sip:trader@pc2.example.com SIP/2.0 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK3 Max-Forwards: 70 To: Bob ;tag=200 From: Alice ;tag=100 Call-ID: abcd1234@pc1.example.com CSeq: 2 INFO Info-Package: pw-info-package Content-type: application/pw-info+xml Content-Disposition: Info-Package Content-Length: 109 The Trading Desk sends a 200 OK(5) request. Beauchamp, et al. Expires January 31, 2014 [Page 12] Internet-Draft SIP INFO Package for Private Wire July 2013 SIP/2.0 200 OK Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK3 Max-Forwards: 70 To: Bob ;tag=200 From: Alice ;tag=100 Call-ID:abcd1234@pc1.example.com CSeq: 2 INFO Content-Length: 0 The NWG sends an INFO(6) request. The INFO request contains a 'pw' package payload signalling 'on hook'. INFO sip:trader@pc2.example.com SIP/2.0 Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK4 Max-Forwards: 70 To: Bob ;tag=200 From: Alice ;tag=100 Call-ID:abcd1234@pc1.example.com CSeq: 3 INFO Info-Package: pw-info-package Content-type: application/pw-info+xml Content-Disposition: Info-Package Content-Length: 108 The Trading Desk sends a 200 OK(7) request. SIP/2.0 200 OK Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK4 Max-Forwards: 70 To: Bob ;tag=200 From: Alice ;tag=100 Call-ID: abcd1234@pc1.example.com CSeq: 3 INFO Content-Length: 0 9. Formal Syntax Beauchamp, et al. Expires January 31, 2014 [Page 13] Internet-Draft SIP INFO Package for Private Wire July 2013 Version 0.1 Draft XML schema for Private Wire Signalling in SIP INFO body Beauchamp, et al. Expires January 31, 2014 [Page 14] Internet-Draft SIP INFO Package for Private Wire July 2013 10. Legacy Interoperation Beauchamp, et al. Expires January 31, 2014 [Page 15] Internet-Draft SIP INFO Package for Private Wire July 2013 The existing install base of PW are made up of E1/T1 CAS or analogue circuits and in order to interoperate with the legacy equipment a gateway function is required. There are a number of different signalling types in use and it will be the job of the gateway to map the legacy signalling to the proposed SIP INFO messages. A number of gateways that exist have solved this problem using RFC 2833 [RFC2833] which allows call events on trunks to be sent in the media plane as RTP packets. Gateway devices or Session Border Controller (SBC) devices implementing this new SIP based signalling should to be able to inter operate with this standard and to be able to translate between the two worlds. 11. Security Considerations Security Considerations to be included in later versions of this document. 12. IANA Considerations 12.1. application/pw-info+xml MIME type This section registers the "application/pw-info+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/pw-info+xml MIME media type name: application MIME subtype name: pw-info+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], section 3.2. Security considerations: No known security considerations outside of those provided by the Private Wire SIP INFO Package. Interoperability considerations: This content type provides constructs for the Private Wire SIP INFO Package. Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] Applications which use this media type: Implementations of the Private Wire SIP INFO package. Additional Information: Magic Number(s): (none) File extension(s): (none) Macintosh File Type Code(s): (none) Person & email address to contact for further information: Chris Beauchamp, et al. Expires January 31, 2014 [Page 16] Internet-Draft SIP INFO Package for Private Wire July 2013 Boulton Intended usage: LIMITED USE Author/Change controller: The IETF Other information: None. 12.2. pw-info-package SIP OPTIONS tag This section defines a new SIP option tag per the guidelines in Section 27.1 of RFC 3261 [RFC3261]. Name: pw-info-package Description: This option tag is used to identify the Private Wire INFO package extension. When present in a Require header field, it indicates that Private Wire is required by a receiving client. 13. Change Summary This section will document changes made in future versions. 14. Acknowledgements The authors would like to thank John Stafford and David Cohen of BT for their input. 15. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002. Beauchamp, et al. Expires January 31, 2014 [Page 17] Internet-Draft SIP INFO Package for Private Wire July 2013 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, January 2011. Authors' Addresses Richard Beauchamp Unaffiliated Finlay Fraser BT Trading Systems Email: finlay.fraser_AT_bt.com Chris Boulton NS-Technologies Email: chris@ns-technologies.com Beauchamp, et al. Expires January 31, 2014 [Page 18]