One document matched: draft-elwell-sipping-qsig-tunnel-02.txt
Differences from draft-elwell-sipping-qsig-tunnel-01.txt
Internet Engineering Task Force J. Elwell
Internet Draft Siemens
J. McMillen
Avaya
JF. Rey/O. Rousseau
draft-elwell-sipping-qsig-tunnel-02.txt Alcatel
Expires: June 2005 December 2004
Tunnelling of QSIG over SIP
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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. "
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document specifies tunnelling of "QSIG" over the Session
Initiation Protocol (SIP). This enables calls between "islands" of
circuit switched networks that use QSIG signalling to be
interconnected by an IP network that uses SIP signalling without loss
of QSIG functionality.
Elwell et alia Expires - June 2005 [Page 1]
Tunnelling of QSIG over SIP December 2004
This document is a product of the authors' activities in Ecma
(www.ecma-international.org) on interoperability of QSIG with IP
networks.
1 Introduction....................................................2
2 Terminology.....................................................3
3 Definitions.....................................................3
3.1 External definitions..........................................4
3.2 Other definitions.............................................4
3.2.1 Corporate telecommunication Network (CN)....................4
3.2.2 Egress gateway..............................................4
3.2.3 Gateway.....................................................4
3.2.4 Ingress gateway.............................................4
3.2.5 IP network..................................................4
3.2.6 Media stream................................................4
3.2.7 Private Integrated Services Network (PISN)..................5
3.2.8 Private Integrated services Network eXchange (PINX).........5
4 Acronyms........................................................5
5 Background and architecture.....................................5
6 Procedures......................................................8
6.1 General.......................................................8
6.2 Encapsulation of QSIG messages in SIP messages................8
6.3 QSIG SETUP message handling at an ingress gateway.............8
6.3.1 Sending a SIP INVITE request................................8
6.3.2 Receipt of responses to the INVITE request..................9
6.4 QSIG SETUP message handling at an egress gateway.............10
6.4.1 Receiving a SIP INVITE request.............................10
6.4.2 Rejecting a QSIG message in an INVITE request..............11
6.5 Subsequent QSIG messages.....................................11
6.6 Terminating the SIP dialog...................................11
7 Example message sequences......................................11
7.1 Call establishment...........................................11
7.2 Call clearing................................................12
7.3 Call establishment with m=0 in first SDP answer..............13
8 Security considerations........................................14
9 IANA considerations............................................15
10 Authors' Addresses............................................15
11 Normative References..........................................15
Annex A - Change log...................Error! Bookmark not defined.
1 Introduction
This document specifies tunnelling of "QSIG" over the Session
Initiation Protocol (SIP) within a corporate telecommunication
network (CN).
"QSIG" is a signalling protocol that operates between Private
Integrated Services eXchanges (PINX) within a Private Integrated
Elwell et alia Expires - June 2005 [Page 2]
Tunnelling of QSIG over SIP December 2004
Services Network (PISN). A PISN provides circuit-switched basic
services and supplementary services to its users. QSIG is specified
in Ecma Standards, in particular [2] (call control in support of
basic services), [3] (generic functional protocol for the support of
supplementary services) and a number of Standards specifying
individual supplementary services.
NOTE. The name QSIG was derived from the fact that it is used for
signalling at the Q reference point. The Q reference point is a point
of demarcation between two PINXs.
SIP is an application layer protocol for establishing, terminating
and modifying multimedia sessions. It is typically carried over IP
[6], [7]. Telephone calls are considered as a type of multimedia
session where just audio is exchanged. SIP is defined in [1].
Often a CN comprises both PISNs employing QSIG and IP networks
employing SIP. A call can originate at a user connected to a PISN and
terminate at a user connected to an IP network or vice versa. In
either case, a gateway provides interworking between QSIG and SIP at
the boundary between the PISN and the IP network. Basic call
interworking at a gateway is specified in [5]. Another case is where
a call originates at a user connected to a PISN, traverses an IP
network using SIP, and terminates at a user connected to another (or
another part of the same) PISN. This document addresses this last
case in a way that preserves all QSIG capabilities across the IP
network. It achieves this by tunnelling QSIG messages within SIP
requests and responses in the context of a SIP dialog.
The tunnelling of QSIG through a public IP network employing SIP is
outside the scope of this specification. However, the functionality
specified in this specification is in principle applicable to such a
scenario when deployed in conjunction with other relevant
functionality (e.g., address translation, security functions, etc.).
This specification is applicable to any interworking unit that can
act as a gateway between a PISN employing QSIG and a corporate IP
network employing SIP, with QSIG tunnelled within SIP requests and
responses.
2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant SIP implementations.
3 Definitions
Elwell et alia Expires - June 2005 [Page 3]
Tunnelling of QSIG over SIP December 2004
For the purposes of this specification, the following definitions
apply.
3.1 External definitions
The definitions in [2] and [1] apply as appropriate.
3.2 Other definitions
3.2.1 Corporate telecommunication Network (CN)
Sets of privately-owned or carrier-provided equipment that are
located at geographically dispersed locations and are interconnected
to provide telecommunication services to a defined group of users.
NOTE. A CN can comprise a PISN, a private IP network (intranet) or a
combination of the two.
3.2.2 Egress gateway
A gateway handling a QSIG call or call-independent signalling
connection established in the direction IP network to PISN.
3.2.3 Gateway
An entity that behaves as a QSIG Transit PINX with QSIG carried over
a circuit-switch link within a PISN on one side and QSIG tunnelled
over SIP within an IP network on the other side.
3.2.4 Ingress gateway
A gateway handling a QSIG call or call-independent signalling
connection established in the direction PISN to IP network.
3.2.5 IP network
A network, unless otherwise stated a corporate network, offering
connectionless packet-mode services based on the Internet Protocol
(IP) as the network layer protocol.
3.2.6 Media stream
Audio or other user information transmitted in UDP packets, typically
containing RTP, in a single direction between the gateway and a peer
entity participating in a session established using SIP.
NOTE. Normally a SIP session establishes a pair of media streams, one
in each direction.
Elwell et alia Expires - June 2005 [Page 4]
Tunnelling of QSIG over SIP December 2004
3.2.7 Private Integrated Services Network (PISN)
A CN or part of a CN that employs circuit-switched technology and
QSIG signalling.
3.2.8 Private Integrated services Network eXchange (PINX)
A PISN nodal entity comprising switching and call handling functions
and supporting QSIG signalling in accordance with [2].
4 Acronyms
IP Internet Protocol
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
RTP Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
TLS Transport Layer Security
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
5 Background and architecture
This document concerns the case of a call that originates at a user
connected to a PISN employing QSIG, traverses an IP network employing
SIP, and terminates at a user connected to another (or another part
of the same) PISN. This can be achieved by employing a gateway at
each boundary between a PISN employing QSIG and an IP network
employing SIP, as shown in Figure 1.
PISN IP network (SIP) PISN
(QSIG) <-----------------------> (QSIG)
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|PINX | |Gate-| |SIP | |SIP | |Gate-| |PINX |
| |---|way |---|proxy|---|proxy|---|way |---| |
| | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 1 û Call from QSIG via SIP to QSIG
Each gateway can provide interworking as specified in [5]. This
provides a basic call capability. However, [5] only specifies
interworking for QSIG basic call, as specified in [2]. Many of the
other capabilities of QSIG (support for supplementary services and
additional network features) as specified in other standards and in
Elwell et alia Expires - June 2005 [Page 5]
Tunnelling of QSIG over SIP December 2004
vendor-specific specifications are not covered. Some of these
additional capabilities of QSIG are suitable for interworking with
SIP and might be the subject of future informational RFCs or other
specifications. Other capabilities of QSIG are unsuitable for
interworking with SIP because corresponding capabilities do not exist
in SIP or are achieved in ways that are incompatible with QSIG.
Therefore interworking at a gateway between QSIG and SIP will be
limited to those QSIG capabilities that have sufficiently compatible
equivalents in SIP. Each capability requires special implementation
in the gateway, and therefore a typical gateway might provide
interworking for only a subset of capabilities for which interworking
is feasible.
The result of this is that there will be a loss of capability on a
call from QSIG to SIP or vice versa. For a call similar to that shown
in figure 1 there will likewise be a loss of capability. This can be
compounded if the two gateways are of different types, since only
those capabilities common to both gateways will survive end-to-end.
The solution is to tunnel QSIG messages through the IP network within
SIP messages so that no end-to-end QSIG capabilities are lost. One of
the two gateways originates a SIP dialog to the other gateway. SIP
messages within the dialog are used to tunnel QSIG messages. Through
the use of SDP, the dialog also establishes a session in which media
streams carry user information (e.g., speech) between the two QSIG
gateways. The two gateways act as QSIG Transit PINXs, which relay
QSIG messages with little or no modification.
In a conventional PISN employing QSIG, two PINXs are connected by
means of an inter-PINX link, which comprises a signalling channel
(carrying QSIG messages) and one or more user information channels
carrying speech, modem information or data. With the tunnelling
solution, the IP network provides the inter-PINX link between the two
gateways acting as Transit PINXs. The tunnel provided by SIP for QSIG
messages acts as the signalling channel and the media streams act as
the user information channels.
This document restricts itself to the case where a single dialog
between two gateways is used for a single QSIG call. This means that
the dialog is established when the QSIG call is established and
cleared down when the QSIG call is cleared down. An enhanced scenario
in which a single SIP dialog is maintained long term and used to
tunnel a multiplicity of QSIG calls, with the possibility of multiple
QSIG calls being in progress at any one time, is outside the scope of
this document.
This document also covers the case where a dialog between two
gateways supports a call-independent signalling connection, as
specified in [3]. The support of call-independent connectionless
Elwell et alia Expires - June 2005 [Page 6]
Tunnelling of QSIG over SIP December 2004
transport, as specified in [3], is outside the scope of this
document.
When a gateway (the ingress gateway) receives a QSIG call or call-
independent signalling connection establishment request (QSIG SETUP
message) from the PISN, it needs to generate a SIP INVITE request
using a Request-URI that will route the request to an appropriate
egress gateway. The Request-URI must be derived in some way from the
required destination of the QSIG call or call-independent signalling
connection (as indicated in the Called party number information
element of the QSIG SETUP message). The Request-URI can explicitly
identify the egress gateway or it can simply identify the required
destination. The first case is likely to require some sort of look-up
capability in the gateway, the configuration of which is outside the
scope of this document. For the latter case algorithmic mapping of
the called party number to a Request-URI might be sufficient, but
this delegates the task of selecting an appropriate egress gateway to
SIP proxies.
An ingress gateway may determine from the required destination of a
call or call-independent signalling connection that the destination
is not reachable via QSIG tunnelling. In this case the QSIG gateway
can either route the call or call-independent signalling connection
onwards within the PISN or can route the call or call-independent
signalling connection into the IP network using interworking as
specified in [5]. How an ingress gateway determines that the
destination is not reachable via QSIG tunnelling is outside the scope
of this document.
If an ingress gateway maps the QSIG called party number to a Request
URI that does not explicitly identify a particular egress gateway,
routing of the INVITE request is left to SIP proxies. A proxy might
route the request to a UAS that is not an egress gateway to QSIG, in
which case QSIG tunnelling will not be possible. Allowing the call or
call-independent signalling connection to proceed in this situation
is likely to be undesirable, since the ingress gateway expects to
carry out QSIG tunnelling whereas interworking with SIP, as specified
in [5], would be more appropriate. To cater for this situation, a
mechanism is defined that causes an INVITE request containing
tunnelled QSIG to be rejected by an egress gateway that does not
support this capability.
NOTE. Allowing the INVITE request to be routed by proxies either to
an egress gateway to QSIG or to some other UAS without the ability
for the ingress gateway to choose in advance is undesirable. It
implies that the ingress gateway maps the QSIG SETUP message to a SIP
INVITE request in accordance with both this document and [5]
simultaneously. Although this may seem feasible superficially,
architecturally it is dangerous because with QSIG tunnelling the
Elwell et alia Expires - June 2005 [Page 7]
Tunnelling of QSIG over SIP December 2004
ingress gateway should act as a QSIG Transit PINX whereas with
interworking in accordance with [5] it should act as a QSIG Outgoing
Gateway PINX. The ingress gateway will not know for certain which
behaviour to adopt until a 200 OK arrives, and therefore in the
meantime it will not know how to handle information relating to
certain QSIG capabilities (supplementary services and additional
network features) in the QSIG SETUP message. It is not clear whether
this can be handled safely for all possible QSIG capabilities
(including vendor-specific capabilities). For this reason, this
specification and [5] require the ingress gateway to make a decision
between tunnelling and interworking respectively.
6 Procedures
6.1 General
A gateway SHALL behave as a QSIG Transit PINX as specified in [2] and
modified as specified below.
6.2 Encapsulation of QSIG messages in SIP messages
When encapsulating a QSIG message inside a SIP message, a gateway
SHALL include the QSIG message in a MIME body of the SIP request or
response in accordance with [8] using media type application/QSIG.
QSIG segmentation SHALL NOT apply.
If any other MIME body is to be included (e.g., SDP), the gateway
SHALL use multi-part MIME.
The gateway SHALL include a Content-Disposition header indicating
"signal" and "handling=required" as a SIP header (in the case of
single-part MIME) or as a MIME header in the body containing the QSIG
message (in the case of multi-part MIME).
6.3 QSIG SETUP message handling at an ingress gateway
6.3.1 Sending a SIP INVITE request
The ingress gateway, on receipt of a QSIG SETUP message eligible for
tunnelling over SIP to an egress gateway, SHALL build a SIP INVITE
request message containing a Request-URI suitable for routing towards
a suitable egress.
NOTE. The Request-URI should be derived in some way from the Called
party number information in the QSIG SETUP message. The Request-URI
can explicitly identify a particular egress gateway. Alternatively it
can identify the final destination in a way that leaves selection of
a suitable egress gateway to SIP proxies.
Elwell et alia Expires - June 2005 [Page 8]
Tunnelling of QSIG over SIP December 2004
The From header should contain a URI identifying either the ingress
gateway or the calling party (derived from the QSIG Calling party
number information element).
The ingress gateway SHALL encapsulate the QSIG SETUP message in the
SIP INVITE request.
The encapsulated QSIG SETUP message MAY differ from the received
SETUP message in accordance with acceptable modification at a QSIG
Transit PINX. For example, the Channel identification information
element MAY change. Because in the encapsulated QSIG SETUP message
the contents of the Channel identification information element have
no significance, the channel number field SHOULD contain value 1 and
the preferred/exclusive field SHOULD contain value 1 (exclusive).
For call establishment the INVITE request SHALL contain an SDP offer
proposing a pair of media streams, one in each direction, that the
gateway can map to the user information channel indicated in the
Channel identification information element in the received QSIG
message. The media streams SHALL be suitable for use in accordance
with the Bearer capability information element in the received QSIG
SETUP message. For call-independent signalling connection
establishment the INVITE request SHALL contain an SDP offer
containing zero "m=" lines.
After sending the SIP INVITE request, the ingress gateway SHALL NOT
encapsulate any further message from QSIG until a SIP 200 OK response
has been received.
6.3.2 Receipt of responses to the INVITE request
The action specified below is in addition to normal UA handling of a
SIP response.
On receipt of a SIP 4xx, 5xx or 6xx final response, the ingress
gateway SHALL either take alternative action to route the call or
call-independent signalling connection (outside the scope of this
document) or clear the call or call-independent signalling connection
using an appropriate cause value in the QSIG Cause information
element of the QSIG clearing message concerned (DISCONNECT, RELEASE
or RELEASE COMPLETE). The ingress gateway SHOULD choose a cause that
reflects the fact that the next PINX cannot be reached (e.g., Cause
value 3 "no route to destination").
NOTE. A SIP 415 Unsupported Media Type final response can be expected
if the UAS does not support encapsulated QSIG.
On receipt of a SIP 200 OK response, the ingress gateway SHALL carry
out normal SIP processing, including transmission of an ACK request,
Elwell et alia Expires - June 2005 [Page 9]
Tunnelling of QSIG over SIP December 2004
and SHALL act upon any encapsulated QSIG message. The ingress gateway
SHALL also connect the QSIG user information channel to the media
streams indicated in the SDP answer if able to do so.
NOTE. If an "m=" line indicates port 0 the ingress gateway will be
unable to start the media stream in the direction ingress to egress
at this stage. 2-way connection will be achieved after a successful
re-INVITE or UPDATE [10] transaction.
6.4 QSIG SETUP message handling at an egress gateway
6.4.1 Receiving a SIP INVITE request
On receipt of a SIP INVITE request containing a QSIG message in the
body of the request, the egress gateway SHALL send a SIP 200 OK
response containing an SDP answer. The SDP answer SHOULD establish
symmetrical media streams, unless the SDP answer contained zero "m="
lines (for a call-independent signalling connection).
If the egress gateway cannot determine appropriate SDP parameters at
the time the SDP answer is to be sent, the egress gateway SHALL send
an SDP answer in which the "m=" lines indicate port 0. In this case
the IP address in the "c=" line is unimportant but may, for example,
be that of the SIP signalling part of the egress gateway. When the
SDP parameters are available at a later stage of QSIG call
establishment, the egress gateway SHALL re-negotiate media streams
using a SIP re-INVITE request or SIP UPDATE [10] request with an
appropriate SDP offer.
If the QSIG message is a SETUP message acceptable for routing onwards
into the PISN, the egress gateway SHALL select a user information
channel on the PISN side and shall forward the QSIG SETUP message.
The forwarded QSIG SETUP message MAY differ from the received SETUP
message in accordance with acceptable modification at a QSIG Transit
PINX. In particular, the Channel identification information element
SHALL reflect the selected user information channel. For call
establishment the egress gateway SHALL also connect the QSIG user
information channel to the established media streams.
The egress gateway MAY include in the SIP 200 response an
encapsulated QSIG SETUP ACKNOWLEDGE message or CALL PROCEEDING
message. Otherwise the gateway SHALL transmit this first responding
QSIG message later in a SIP INFO message in accordance with 6.5.
NOTE. The egress gateway may reject a SIP INVITE request in
accordance with [1]. For example, if the SIP UAS does not support
encapsulated QSIG and therefore is not capable of being an egress
gateway, SIP response code 415 Unsupported Media Type will apply. If
the SIP UAS is unable to accept the SDP offer, SIP response code 488
Elwell et alia Expires - June 2005 [Page 10]
Tunnelling of QSIG over SIP December 2004
Not Acceptable Here will apply. However, an egress gateway that is
unable to validate the SDP offer prior to sending a SIP 200 response
will accept the offer and use a SIP re-INVITE request or SIP UPDATE
request later to re-negotiate media streams.
6.4.2 Rejecting a QSIG message in an INVITE request
If the egress gateway contains an INVITE request containing a QSIG
message that is not acceptable (e.g., a SETUP message not suitable
for routing onwards, a message other than a SETUP message, a SETUP
message for a call for which suitable media streams have not been
established) the egress gateway SHALL send back a responding QSIG
message in accordance with [2] or [3], e.g, a RELEASE COMPLETE
message containing an appropriate value in the QSIG Cause information
element. The responding QSIG message shall be sent either in an INFO
message in accordance with 6.5 or, in the case of a RELEASE COMPLETE
message, in a BYE message in accordance with 6.6.
6.5 Subsequent QSIG messages
After receipt transmitting a 200 OK response (egress gateway) or
transmitting an ACK following receipt of a 200 OK response (ingress
gateway), a gateway SHALL encapsulate any further QSIG messages for
transmission to the peer gateway in the body of a SIP INFO request
[9] and SHALL be able to receive further QSIG messages from the peer
gateway encapsulated in the body of SIP INFO request. The exceptions
are:
- a SIP BYE request, which MAY encapsulate a QSIG RELEASE COMPLETE
message, in accordance with 6.6; and
- a SIP re-INVITE request or SIP UPDATE request, which MAY
encapsulate a waiting QSIG message during QSIG call establishment.
6.6 Terminating the SIP dialog
When a gateway determines that a QSIG call or call-independent
signalling connection has terminated, it SHALL terminate the SIP
session by transmitting a BYE request. If a gateway transmits the
final QSIG message of the call or call-independent signalling
connection (RELEASE COMPLETE), the gateway MAY encapsulate that QSIG
message in the BYE request. Otherwise the gateway SHALL transmit the
BYE request after the final QSIG message has been sent or received
and SHALL NOT encapsulate a QSIG message in the BYE request.
7 Example message sequences
7.1 Call establishment
IP network
Elwell et alia Expires - June 2005 [Page 11]
Tunnelling of QSIG over SIP December 2004
+-----------+ (SIP with +-----------+
PISN |Ingress | tunnelled |Egress | PISN
(QSIG) |gateway | QSIG) |gateway | (QSIG)
+-----------+ +-----------+
QSIG SETUP || SIP INVITE request ||
----------------->|| QSIG SETUP ||
|| ||
QSIG CALL ||----------------------->|| QSIG SETUP
PROCEEDING || ||----------------->
<-----------------|| SIP 200 OK ||
|| QSIG CALL PROCEEDING || QSIG CALL
||<-----------------------|| PROCEEDING
|| ||<-----------------
|| SIP ACK ||
||----------------------->||
|| || QSIG ALERTING
|| SIP INFO ||<-----------------
|| QSIG ALERTING ||
||<-----------------------||
QSIG ALERTING || ||
<-----------------|| SIP 200 OK ||
||----------------------->||
|| || QSIG CONNECT
|| SIP INFO ||<-----------------
|| QSIG CONNECT ||
||<-----------------------|| QSIG CONNECT ACK
QSIG CONNECT || ||----------------->
<-----------------|| SIP 200 OK ||
||----------------------->||
|| ||
|| SIP INFO ||
|| QSIG CONNECT ACK ||
||----------------------->||
QSIG CONNECT ACK || ||
----------------->|| SIP 200 OK ||
||<-----------------------||
|| ||
Figure 2 û Call establishment QSIG-SIP-QSIG
7.2 Call clearing
IP network
+-----------+ (SIP with +-----------+
PISN |Ingress | tunnelled |Egress | PISN
(QSIG) |gateway | QSIG) |gateway | (QSIG)
+-----------+ +-----------+
QSIG DISCONNECT || SIP INFO ||
----------------->|| QSIG DISCONNECT ||
Elwell et alia Expires - June 2005 [Page 12]
Tunnelling of QSIG over SIP December 2004
||----------------------->|| QSIG DISCONNECT
QSIG RELEASE || ||----------------->
<-----------------|| SIP 200 OK ||
||<-----------------------||
QSIG RELEASE || ||
COMPLETE || SIP INFO ||
----------------->|| QSIG RELEASE ||
||<-----------------------|| QSIG RELEASE
|| ||<-----------------
|| ||
|| || QSIG RELEASE
|| || COMPLETE
|| SIP 200 OK ||----------------->
||----------------------->||
|| ||
|| SIP BYE ||
|| QSIG RELEASE COMPLETE ||
||----------------------->||
|| ||
|| SIP 200 OK ||
||<-----------------------||
|| ||
Figure 3 û Call clearing QSIG-SIP-QSIG
7.3 Call establishment with m=0 in first SDP answer
IP network
+-----------+ (SIP with +-----------+
PISN |Ingress | tunnelled |Egress | PISN
(QSIG) |gateway | QSIG) |gateway | (QSIG)
+-----------+ +-----------+
QSIG SETUP || SIP INVITE request ||
----------------->|| with SDP offer ||
|| QSIG SETUP ||
QSIG CALL ||----------------------->|| QSIG SETUP
PROCEEDING || ||----------------->
<-----------------|| SIP 200 OK ||
|| with SDP answer (m=0) ||
|| QSIG CALL PROCEEDING || QSIG CALL
||<-----------------------|| PROCEEDING
|| ||<-----------------
|| SIP ACK ||
||----------------------->||
|| || QSIG ALERTING
|| SIP UPDATE ||<-----------------
|| with SDP offer ||
|| QSIG ALERTING ||
||<-----------------------||
Elwell et alia Expires - June 2005 [Page 13]
Tunnelling of QSIG over SIP December 2004
QSIG ALERTING || ||
<-----------------|| SIP 200 OK ||
|| with SDP answer ||
||----------------------->||
|| || QSIG CONNECT
|| SIP INFO ||<-----------------
|| QSIG CONNECT ||
||<-----------------------|| QSIG CONNECT ACK
QSIG CONNECT || ||----------------->
<-----------------|| SIP 200 OK ||
||----------------------->||
|| ||
|| SIP INFO ||
|| QSIG CONNECT ACK ||
||----------------------->||
QSIG CONNECT ACK || ||
----------------->|| SIP 200 OK ||
||<-----------------------||
|| ||
Figure 4 û Call establishment QSIG-SIP-QSIG with m=0 in SDP answer in
SIP 200 response to INVITE request
8 Security considerations
QSIG can contain potentially sensitive information, i.e., numbers and
names of call participants. Therefore a gateway needs to take care
that any QSIG information it transmits is sent only to trusted QSIG
gateways and cannot be accessed by third parties. Furthermore a
gateway needs to be sure of the source and integrity of any QSIG
information it receives, to avoid harming or sending misleading
information to the QSIG network.
A gateway SHALL support the transport of SIP over Transport Layer
Security (TLS) and the use of the SIPS URI as defined in [1] for
identifying the gateway and for establishing a call or call-
independent signalling connection to a peer gateway. In addition a
gateway SHALL either be able to act as a TLS server, which requires
it to have its own private key and certificate, or support the
retention of TLS connections for use by incoming SIP calls or call-
independent signalling connections.
NOTE. Support of TLS and SIPS meet the security requirements to the
extent that each link (between gateway and proxy and between
proxies) is secured. This is sufficient in a typical enterprise
environment, where proxies can be trusted.
Elwell et alia Expires - June 2005 [Page 14]
Tunnelling of QSIG over SIP December 2004
In addition, a gateway MAY support the use of S/MIME for securing a
QSIG body in accordance with [1].
NOTE. This avoids the need for trusted proxies, but requires each
gateway to have a private key and certificate.
9 IANA considerations
None
10 Authors' Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
Joanne McMillen
Avaya Inc.
1300 W. 120th Ave.
Westminster, CO 80234-2726
email: joanne@avaya.com
Olivier Rousseau
Alcatel Business Systems
32,Avenue Kleber
92700 Colombes
France
email: olivier.rousseau@alcatel.fr
Jean-Francois Rey
Alcatel Business Systems
8,Rue de Kervezennec, BP 82 802
29228 Brest Cedex 2
France
email: jean-francois.rey@alcatel.fr
11 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[2] International Standard ISO/IEC 11572 "Private Integrated Services
Network - Circuit-mode Bearer Services - Inter-Exchange Signalling
Procedures and Protocol" (also published by Ecma as Standard
ECMA-143)
Elwell et alia Expires - June 2005 [Page 15]
Tunnelling of QSIG over SIP December 2004
[3] International Standard ISO/IEC 11582 "Private Integrated Services
Network - Generic Functional Protocol for the Support of
Supplementary Services - Inter-Exchange Signalling Procedures and
Protocol" (also published by Ecma as Standard ECMA-165)
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] F. Derks, J. Elwell, P. Mourot, O. Rousseau, "Interworking
between SIP and QSIG", draft-ietf-sipping-qsig2sip-04
[6] J. Postel, "Internet Protocol", RFC 791.
[7] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)",
RFC 2460.
[8] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
objects", RFC 3204, December 2001.
[9] Donovan, S., "The SIP INFO Method", RFC2976, October 2000.
[10] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
message", RFC3311, September 2002.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Elwell et alia Expires - June 2005 [Page 16]
Tunnelling of QSIG over SIP December 2004
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Annex A (temporary) - Change log
Changes since version 01:
- Support for QSIG call-independent signalling connections added.
- Clarification on the use of MIME headers.
- Clarification on QSIG cause values.
- Clarification on rejecting a QSIG message inside a SIP INVITE
request.
- Provision added for dummy SDP answer to be used in situations where
a real SDP answer is not available in time for the SIP 200 response
to the SIP INVITE request.
- Support for QSIG tunnelling in UPDATE and re-INVITE requests added.
- Security considerations added.
- All open issues resolved.
Elwell et alia Expires - June 2005 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 00:11:50 |