There is another class of potential risk that is related to the cut-
through of the backwards media path before the call is answered.
Several practices described in this document involve the connection
of media streams to user information channels on inter-PINX links and
the sending of progress description number 1 or 8 in a backward QSIG
message. This can result in media being cut through end-to-end, and
it is possible for the called user agent then to play arbitrary audio
to the caller for an indefinite period of time before transmitting a
final response (in the form of a 2xx or higher response code) to an
INVITE request. This is useful since it also permits network
entities (particularly legacy networks that are incapable of
transmitting Q.850 cause values) to play tones and announcements to
indicate call failure or call progress, without triggering charging
by transmitting a 2xx response. Also, early cut-through can help
prevent clipping of the initial media when the call is answered.
There are conceivable respects in which this capability could be used
fraudulently by the called user agent for transmitting arbitrary
information without answering the call or before answering the call.
However, in corporate networks, charging is often not an issue, and
for calls arriving at a corporate network from a carrier network, the
carrier network normally takes steps to prevent fraud.
The usefulness of this capability appears to outweigh any risks
involved, which may in practice be no greater than in existing
PISN/ISDN environments. However, gateway implementers may wish to
make provision for gateway administrators to turn off cut-through or
minimise its impact (e.g., by imposing a time limit) when deployed in
situations where problems can arise.
11.7. Protection from Denial-of-Service Attacks
Unlike a traditional PISN phone, a SIP user agent can launch multiple
simultaneous requests in order to reach a particular resource. It
would be trivial for a SIP user agent to launch 100 SIP INVITE
requests at a 100 port gateway, thereby tying up all of its ports. A
malicious user could choose to launch requests to telephone numbers
that are known never to answer, or, where overlap signalling is used,
to incomplete addresses. This could saturate resources at the
gateway indefinitely, potentially without incurring any charges.
Gateway implementers may therefore wish to provide means of
restricting according to policy the number of simultaneous requests
originating from the same authenticated source, or similar mechanisms
to address this possible denial-of-service attack.
12. Acknowledgements
This document is a product of the authors’ activities in Ecma
(www.ecma-international.org) on interoperability of QSIG with IP
networks. An earlier version is published as Standard ECMA-339.
Ecma has made this work available to the IETF as the basis for
publishing an RFC.
The authors wish to acknowledge the assistance of Francois Audet,
Adam Roach, Jean-Francois Rey, Thomas Stach, and members of Ecma
TC32-TG17 in preparing and commenting on this document.
13. Normative References
[1] International Standard ISO/IEC 11571 "Private Integrated
Services Networks (PISN) - Addressing" (also published by Ecma
as Standard ECMA-155).
[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).
[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] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[10] 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.
[11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[14] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[16] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[17] ITU-T Recommendation E.164, "The International Public
Telecommunication Numbering Plan", (1997-05).
[18] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of
Integrated Services Digital Network (ISDN) User Part (ISUP)
Overlap Signalling to the Session Initiation Protocol (SIP)",
RFC 3578, August 2003.
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[20] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
Appendix A. Example Message Sequences
A.1. Introduction
This appendix shows some typical message sequences that can occur for
an interworking between QSIG and SIP. It is informative.
NOTE: For all message sequence diagrams, there is no message mapping
between QSIG and SIP unless explicitly indicated by dotted lines.
Also, if there are no dotted lines connecting two messages, this
means that these are independent of each other in terms of the time
when they occur.
NOTE: Numbers prefixing SIP method names and response codes in the
diagrams represent sequence numbers. Messages bearing the same
number will have the same value in the CSeq header.
NOTE: In these examples, SIP provisional responses (other than 100)
are shown as being sent reliably, using the PRACK method for
acknowledgement.
A.2. Message Sequences for Call Establishment from QSIG to SIP
Below are typical message sequences for successful call establishment
from QSIG to SIP
A.2.1. QSIG to SIP, using en bloc procedures on both QSIG and SIP
+-------------------+
| |
| GATEWAY |
PISN | | IP NETWORK
| +-----+------+------+ |
| | | |
| | | |
| QSIG SETUP | | 1-INVITE |
1|----------------------->|......|----------------------->| 2
| | | |
| | | |
| QSIG CALL PROCEEDING | | 1-100 TRYING |
3|<-----------------------| |<-----------------------+ 4
| | | |
| | | |
| QSIG ALERTING | | 1-180 RINGING |
8|<-----------------------|......|<-----------------------+ 5
| | | |
| | | 2-PRACK |
| | |----------------------->| 6
| | | 2-200 OK |
| | |<-----------------------+ 7
| | | |
| QSIG CONNECT | | 1-200 OK |
11|<-----------------------|......|<-----------------------+ 9
| | | |
| QSIG CONNECT ACK | | 1-ACK |
12|----------------------->| |----------------------->| 10
| | | |
|<======================>| |<======================>|
| AUDIO | | AUDIO |
Figure 3: Typical message sequence for successful call establishment
from QSIG to SIP, using en bloc procedures on both QSIG and SIP
1 The PISN sends a QSIG SETUP message to the gateway to begin a
session with a SIP UA.
2 On receipt of the QSIG SETUP message, the gateway generates a SIP
INVITE request and sends it to an appropriate SIP entity in the IP
network based on the called number.
3 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no
more QSIG INFORMATION messages will be accepted.
4 The IP network sends a SIP 100 (Trying) response to the gateway.
5 The IP network sends a SIP 180 (Ringing) response.
6 The gateway may send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header
with option tag 100rel in the initial SIP INVITE request.
7 The IP network sends a SIP 200 (OK) response to the gateway to
acknowledge the SIP PRACK request
8 The gateway maps this SIP 180 (Ringing) response to a QSIG
ALERTING message and sends it to the PISN.
9 The IP network sends a SIP 200 (OK) response when the call is
answered.
10 The gateway sends a SIP ACK request to acknowledge the SIP 200
(OK) response.
11 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
message and sends it to the PISN.
12 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
the QSIG CONNECT message.
A.2.2. QSIG to SIP, using overlap receiving on QSIG and en bloc sending
on SIP
+------------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +--------+-------+-------+ |
1|-------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2|<--------------------------| | |
| | | |
| QSIG INFORMATION | | |
3|-------------------------->| | |
| | | |
| QSIG INFORMATION | | 1-INVITE |
3a|-------------------------->|.......|----------------------->|4
| QSIG CALL PROCEEDING | | 1-100 TRYING |
5|<--------------------------| |<-----------------------|6
| | | |
| QSIG ALERTING | | 1-180 RINGING |
10|<--------------------------|.......|<-----------------------|7
| | | 2-PRACK |
| | |----------------------->|8
| | | 2-200 OK |
| | |<-----------------------|9
| QSIG CONNECT | | 1-200 OK |
13|<--------------------------|.......|<-----------------------|11
| | | |
| QSIG CONNECT ACK | | 1-ACK |
14|-------------------------->| |----------------------->|12
| AUDIO | | AUDIO |
|<=========================>| |<======================>|
Figure 4: Typical message sequence for successful call establishment
from QSIG to SIP, using overlap receiving on QSIG and en bloc sending
on SIP
1 The PISN sends a QSIG SETUP message to the gateway to begin a
session with a SIP UA. The QSIG SETUP message does not contain a
Sending Complete information element.
2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN.
More digits are expected.
3 More digits are sent from the PISN within a QSIG INFORMATION
message.
3a More digits are sent from the PISN within a QSIG INFORMATION
message. The QSIG INFORMATION message contains a Sending Complete
information element.
4 The Gateway generates a SIP INVITE request and sends it to an
appropriate SIP entity in the IP network, based on the called
number.
5 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no
more QSIG INFORMATION messages will be accepted.
6 The IP network sends a SIP 100 (Trying) response to the gateway.
7 The IP network sends a SIP 180 (Ringing) response.
8 The gateway may send back a SIP PRACK request to the IP network
based on the inclusion of a Require header or a Supported header
with option tag 100rel in the initial SIP INVITE request.
9 The IP network sends a SIP 200 (OK) response to the gateway to
acknowledge the SIP PRACK request.
10 The gateway maps this SIP 180 (Ringing) response to a QSIG
ALERTING message and sends it to the PINX.
11 The IP network sends a SIP 200 (OK) response when the call is
answered.
12 The gateway sends an SIP ACK request to acknowledge the SIP 200
(OK) response.
13 The gateway maps this SIP 200 (OK) response to a QSIG CONNECT
message and sends it to the PINX.
14 The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to
the QSIG CONNECT message.
A.2.3. QSIG to SIP, using overlap procedures on both QSIG and SIP
+----------------------+
PISN | GATEWAY | IP NETWORK
| |
| QSIG SETUP +-------+-------+------+ |
1 |------------------------->| | |
| | | |
| QSIG SETUP ACK | | |
2 |<-------------------------| | |
| | | |
| QSIG INFORMATION | | |
3 |------------------------->| | |
| QSIG INFORMATION | | 1-INVITE |
3 |------------------------->|.......|------------------------>|4
| | | 1-484 |
| | |<------------------------|5
| | | 1-ACK |
| | |------------------------>|6
| QSIG INFORMATION | | 2-INVITE |
7 |------------------------->|.......|------------------------>|4
| | | 2-484 |
| | |<------------------------|5
| | | 2-ACK |
| | |------------------------>|6
| | | |
| QSIG INFORMATION | | |
| Sending Complete IE | | 3-INVITE |
8 |------------------------->|.......|------------------------>|10
| QSIG CALL PROCEEDING | | 3-100 TRYING |
9 |<-------------------------| |<------------------------|11
| | | |
| QSIG ALERTING | | 3-180 RINGING |
15|<-------------------------|.......|<------------------------|12
| | | 4-PRACK |
| | |------------------------>|13
| | | 4-200 OK |
| | |<------------------------|14
| QSIG CONNECT | | 3-200 OK |
18|<-------------------------|.......|<------------------------|16
| | | |
| QSIG CONNECT ACK | | 3-ACK |
19|------------------------->| |------------------------>|17
| AUDIO | | AUDIO |