A Session Initiation Protocol (SIP) INFO package for Private Wire
draft-beauchamp-private-wire-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Richard Beauchamp, Finlay Fraser , Chris Boulton | ||
| Last updated | 2012-07-30 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-beauchamp-private-wire-05
Network Working Group R. Beauchamp
Internet-Draft F. Fraser
Intended status: Informational BT Trading Systems
Expires: January 31, 2013 C. Boulton
NS-Technologies
July 30, 2012
A Session Initiation Protocol (SIP) INFO package for Private Wire
draft-beauchamp-private-wire-05
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, 2013.
Copyright Notice
Copyright (c) 2012 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
include Simplified BSD License text as described in Section 4.e of
Beauchamp, et al. Expires January 31, 2013 [Page 1]
Internet-Draft SIP INFO Package for Private Wire July 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
3.1. Overlapping Requests . . . . . . . . . . . . . . . . . . . 8
3.2. Incorrect Private Wire Type . . . . . . . . . . . . . . . 9
4. Private Wire Package Definition . . . . . . . . . . . . . . . 10
4.1. Overall Description . . . . . . . . . . . . . . . . . . . 10
4.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 10
4.3. INFO Package Name . . . . . . . . . . . . . . . . . . . . 10
4.4. INFO Package Parameters . . . . . . . . . . . . . . . . . 10
4.5. SIP OPTION tags . . . . . . . . . . . . . . . . . . . . . 10
4.6. INFO Message Body Parts . . . . . . . . . . . . . . . . . 10
5. Element Definitions . . . . . . . . . . . . . . . . . . . . . 11
5.1. <pwSignal> . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. <ringDown> . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2. <hookSwitch> . . . . . . . . . . . . . . . . . . . . . 12
6. 'pwtype' INFO Package Parameter . . . . . . . . . . . . . . . 13
7. SIP OPTIONS Tag . . . . . . . . . . . . . . . . . . . . . . . 14
8. Example Exchange . . . . . . . . . . . . . . . . . . . . . . . 15
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Legacy Interoperation . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12.1. application/pw-info+xml MIME type . . . . . . . . . . . . 23
12.2. pw-info-package SIP OPTIONS tag . . . . . . . . . . . . . 23
13. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 24
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
15. Normative References . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Beauchamp, et al. Expires January 31, 2013 [Page 2]
Internet-Draft SIP INFO Package for Private Wire July 2012
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.
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
Beauchamp, et al. Expires January 31, 2013 [Page 3]
Internet-Draft SIP INFO Package for Private Wire July 2012
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
+--+--+ +--+--+
| 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
Beauchamp, et al. Expires January 31, 2013 [Page 4]
Internet-Draft SIP INFO Package for Private Wire July 2012
this specification will define the appropriate level of detail from
both a functional and standardisation perspective.
Beauchamp, et al. Expires January 31, 2013 [Page 5]
Internet-Draft SIP INFO Package for Private Wire July 2012
2. Conventions and Terminology
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.
Beauchamp, et al. Expires January 31, 2013 [Page 6]
Internet-Draft SIP INFO Package for Private Wire July 2012
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
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
Beauchamp, et al. Expires January 31, 2013 [Page 7]
Internet-Draft SIP INFO Package for Private Wire July 2012
[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:
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"'.
Beauchamp, et al. Expires January 31, 2013 [Page 8]
Internet-Draft SIP INFO Package for Private Wire July 2012
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].
Beauchamp, et al. Expires January 31, 2013 [Page 9]
Internet-Draft SIP INFO Package for Private Wire July 2012
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.
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.
Beauchamp, et al. Expires January 31, 2013 [Page 10]
Internet-Draft SIP INFO Package for Private Wire July 2012
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 <pwsignal>. All other elements are contained
within it. Child elements are <ringDown> and <hookSwitch>. The
<ringDown> element is described in Section 5.1.1. The <hookSwitch>
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. <pwSignal>
The <pwSignal> element has no attributes in addition to the standard
XML namespace attributes such as xmlns.
The <pwSignal> element has two child elements of which only one can
occur per message.:
o <ringDown> - defined in Section 5.1.1.
o <hookSwitch> - defined in Section 5.1.2.
5.1.1. <ringDown>
The <ringDown> element is used to request a local 'ringdown' alert at
the remote party of the private wire.
The <ringDown> element has the following attributes:
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
Beauchamp, et al. Expires January 31, 2013 [Page 11]
Internet-Draft SIP INFO Package for Private Wire July 2012
The <ringDown> element has no child elements.
5.1.2. <hookSwitch>
The <hookSwitch> element is used to convey a 'hookSwitch' alert to
the remote party of the private wire.
The <hookSwitch> 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 <hookSwitch> element has no child elements.
Beauchamp, et al. Expires January 31, 2013 [Page 12]
Internet-Draft SIP INFO Package for Private Wire July 2012
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 <ringDown> element MUST be used from
Section 9. By specifying a value of 'hookswitch' in the 'pw-type'
parameter the <hookSwitch> 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 ABNF for the 'pw-type' parameter is shown below.
pw-type = "pw-type" EQUAL pwtype
pwtype = "ringdown" / "hookswitch" / "TOS"
Figure 3
Beauchamp, et al. Expires January 31, 2013 [Page 13]
Internet-Draft SIP INFO Package for Private Wire July 2012
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.
Beauchamp, et al. Expires January 31, 2013 [Page 14]
Internet-Draft SIP INFO Package for Private Wire July 2012
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 |
|**************************|
| |
|(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.
Beauchamp, et al. Expires January 31, 2013 [Page 15]
Internet-Draft SIP INFO Package for Private Wire July 2012
INVITE sip:pw@example.com SIP/2.0
Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK1
Max-Forwards: 70
To: PW <sip:pw@example.com>
From: Bank <sip:bank@example.com>;tag=100
Call-ID: abcd1234@pc1.example.com
CSeq: 1 INVITE
Supported: pw-info-package
Recv-Info: pw-info-package;pw-type=hookswitch
Contact: <sip:bank@pc1.example.com>
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
To: PW <sip:pw@example.com>;tag=200
From: Bank <sip:bank@example.com>;tag=100
Call-ID: abcd1234@pc1.example.com
CSeq: 1 INVITE
Contact: <sip:trader@pc2.example.com>
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 <sip:bob@example.com>;tag=200
From: Alice <sip:alice@example.com>;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'.
Beauchamp, et al. Expires January 31, 2013 [Page 16]
Internet-Draft SIP INFO Package for Private Wire July 2012
INFO sip:trader@pc2.example.com SIP/2.0
Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK3
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=200
From: Alice <sip:alice@example.com>;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
<pwSignal xmlns="urn:tradingsystems:params:xml:ns:private-wire:0">
<hookSwitch signal="offHook"/>
</pwSignal>
The Trading Desk sends a 200 OK(5) request.
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc1.example.com;branch=z9hG4bK3
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=200
From: Alice <sip:alice@example.com>;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 <sip:bob@example.com>;tag=200
From: Alice <sip:alice@example.com>;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
<pwSignal xmlns="urn:tradingsystems:params:xml:ns:private-wire:0">
<hookSwitch signal="onHook"/>
</pwSignal>
Beauchamp, et al. Expires January 31, 2013 [Page 17]
Internet-Draft SIP INFO Package for Private Wire July 2012
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 <sip:bob@example.com>;tag=200
From: Alice <sip:alice@example.com>;tag=100
Call-ID: abcd1234@pc1.example.com
CSeq: 3 INFO
Content-Length: 0
Beauchamp, et al. Expires January 31, 2013 [Page 18]
Internet-Draft SIP INFO Package for Private Wire July 2012
9. Formal Syntax
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:bt-trs:params:xml:ns:private-wire:0"
xmlns="urn:bt-trs:params:xml:ns:private-wire:0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
version="0.1">
<xsd:annotation>
<xsd:documentation xml:lang="en">Version 0.1 Draft XML schema
for Private Wire Signalling in SIP INFO body
</xsd:documentation>
</xsd:annotation>
<!--
####################################################
TOP LEVEL ELEMENT: pwSignal
####################################################
-->
<!-- pwSignal -->
<xsd:complexType name="pwSignallingType">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="ringDown" />
<xsd:element ref="hookSwitch" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="pwSignal" type="pwSignallingType"/>
<!-- ringDown -->
<xsd:complexType name="ringDownType">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="signal" type="ringDownSignalType"
Beauchamp, et al. Expires January 31, 2013 [Page 19]
Internet-Draft SIP INFO Package for Private Wire July 2012
use="required"/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="ringDown" type="ringDownType"/>
<!-- hookSwitch -->
<xsd:complexType name="hookSwitchType">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="signal" type="hookSwitchSignalType"
use="required"/>
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>
<xsd:element name="hookSwitch" type="hookSwitchType"/>
<!--
####################################################
DATATYPES
####################################################
-->
<xsd:simpleType name="ringDownSignalType">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="ring"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="hookSwitchSignalType">
<xsd:restriction base="xsd:token">
<xsd:enumeration value="onHook"/>
<xsd:enumeration value="offHook"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
Beauchamp, et al. Expires January 31, 2013 [Page 20]
Internet-Draft SIP INFO Package for Private Wire July 2012
10. Legacy Interoperation
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.
Beauchamp, et al. Expires January 31, 2013 [Page 21]
Internet-Draft SIP INFO Package for Private Wire July 2012
11. Security Considerations
Security Considerations to be included in later versions of this
document.
Beauchamp, et al. Expires January 31, 2013 [Page 22]
Internet-Draft SIP INFO Package for Private Wire July 2012
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
Boulton <chris@ns-technologies.com>
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.
Beauchamp, et al. Expires January 31, 2013 [Page 23]
Internet-Draft SIP INFO Package for Private Wire July 2012
13. Change Summary
This section will document changes made in future versions.
Beauchamp, et al. Expires January 31, 2013 [Page 24]
Internet-Draft SIP INFO Package for Private Wire July 2012
14. Acknowledgements
The authors would like to thank John Stafford and David Cohen of BT
for their input.
Beauchamp, et al. Expires January 31, 2013 [Page 25]
Internet-Draft SIP INFO Package for Private Wire July 2012
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.
[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.
Beauchamp, et al. Expires January 31, 2013 [Page 26]
Internet-Draft SIP INFO Package for Private Wire July 2012
Authors' Addresses
Richard Beauchamp
BT Trading Systems
Email: richard.beauchamp_AT_bt.com
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, 2013 [Page 27]