Internet Engineering Task Force Adam Roach
Internet Draft Ericsson Inc.
Category: N/A June 1999
Expires January 2000
<draft-roach-sip-isup-parameters-00.txt>
ISUP parameters expected in SIP messages
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.
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.
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
To assure inter-operability between gateways which may choose to
transit ISUP messages inside a SIP network, this document seeks
to outline the types of ISUP messages which an implementation can
sensibly expect to arrive in each given SIP message.
1. Introduction
Many implementors in the voice over IP field are exploring ways
in which SIP can be used for long-haul of standard telephony
traffic. In this model, SIP serves as an interim signalling
protocol while the call is carried over the IP network.
Unfortunately, SIP does not provide fields for most message
parameters found in today's telephony networks.
One of the dominant signalling protocols in use in modern
telephony networks is the Signalling System No. 7 (SS7) ISDN User
Part (ISUP). This general protocol is defined in ITU-T
Recommendations Q.761 ( ref [7] ), Q.762 ( ref [8] ), Q.763 ( ref
[9] ), and Q.764 ( ref [10] ). Adaptations of the ISUP protocol
for the North American continent can be found in ANSI T1.113 (
Roach [Page 1]
Internet Draft ISUP parameters expected in SIP messages June 1999
ref [6] ).
To preserve this ISUP signalling when SIP is used between two
ISUP gateways, it has been proposed that the messages sent over
the SIP network would carry ISUP messages with roughly the same
meaning as their SIP "host" messages (see ref [2] and ref [5] ).
This type of transport is commonly referred to as "ISUP
transparency"
2. Expected ISUP Messages
This chapter outlines which ISUP messages can be expected and
should be handled by SIP to ISUP gateways providing an ISUP
transparency function. Any ISUP messages which arrive at times
other than those described below may safely be treated as an
error which terminates the call.
2.1. INVITE
INVITE messages may contain IAM bodies. For overlap dialing
detected by the ingress gateway, they can be expected to
additionally carry one or more SAM messages; multiple ISUP
messages may be attached as defined in "The multipart/sip-id
media type" ( ref [3] ). [Note: it is currently unclear in this
document whether such behavior is allowed]
2.2. 100 class response to INVITE
INVITE 100 class responses can be expected to carry either ACM or
CPG bodies. Since 100 class responses do not change the SIP call
state, gateways should allow them to carry any arbitrary ISUP
messages which do not cause changes to the call state. It can be
reasonably expected that 100 class responses to INVITE will not
contain ANM, CON, IAM, REL, or RLC messages.
2.3. 200 class response to INVITE
INVITE 200 class responses will carry ANM or CON messages. If the
implementor so desires, they may also carry ACM messages
accompanied by ANM messages (the benefits of doing so are not
obvious; however, there is no reason to prohibit such behavior).
Multiple ISUP messages may be attached as defined in "The
mulitpart/sip-id media type" ( ref [3] ). [Note: it is currently
unclear in this document whether such behavior is allowed]
2.4. 300+ response to INVITE
INVITE responses which terminate the transaction may carry any
number of call terminating messages; specifically, REL, RSC, RLC,
GRS, CGB, and UCIC may be expected in response to these types of
Roach [Page 2]
Internet Draft ISUP parameters expected in SIP messages June 1999
messages.
2.5. ACK
Although normally empty, ACK messages can be expected to carry
RLC messages when acknowledging a 300 class or higher response.
The value of providing transparency for RLC is not immediately
apparent; however, there have been proposals to include, among
other things, billing information in RLC messages for certain
networks. SIP gateways should not preclude this capability unless
absolutely necessary. As an aside, note that intervening proxies'
behavior of locally acknowledging error responses will destroy
the ability to carry RLC messages end to end.
2.6. CANCEL and BYE
As in the case of INVITE error responses, any call terminating
ISUP message can be expected in a CANCEL or BYE request;
specifically: REL, RSC, RLC, GRS, and CGB.
2.7. Response to CANCEL and BYE
CANCEL and BYE responses may contain RLC messages. See section
2.5 for the rationale for transporting RLC messages. Note that
proxies' behavior of locally responding to CANCEL messages has
the same effect as is described in that section.
2.8. INFO
See "The SIP INFO Method" ( ref [4] ) for information on the
proposed semantics and syntax for INFO.
Due to its nature, the INFO method can be expected to carry any
arbitrary ISUP message; however, it can be reasonably expected
that it will not contain messages that make a change to call
state about which the SIP network should be aware; specifically,
it is expected that INFO will not contain ACM, ANM, CON, IAM,
REL, or RLC messages.
2.9. Other Messages
It is expected that neither OPTIONS nor REGISTER requests or
responses will carry ISUP payloads of any type.
3. References
[1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, IETF; March 1999.
[2] Christian Huitema, "The application/ISUP media type",
Roach [Page 3]
Internet Draft ISUP parameters expected in SIP messages June 1999
Internet Draft <draft-ietf-sigtran-mime-isup-00.txt>, IETF;
Feb. 1999. Work in progress.
[3] Christian Huitema, "The multipart/sip-id media type",
Internet Draft <draft-ietf-mmusic-sip-multipart-00.txt>,
IETF; Feb. 1999. Work in progress.
[4] Steven R. Donovan, "The SIP INFO Method", Internet Draft
<draft-ietf-mmusic-sip-info-method-00.txt>, IETF; Feb. 1999.
Work in progress.
[5] Eric Zimmerer, "SIP+ (Inter MGC Protocol)," Edition 0.0,
Draft 0.1, Level 3; Dec. 1998. Work in progress.
[6] "Signalling System No. 7 (SS7) -- Integrated Services Digital
Network (ISDN) User Part", ANSI T1.113-1995; Jan. 1995.
[7] "Functional Description of the ISDN User Part of Signalling
System No. 7", ITU-T Recommendation Q.761; Mar. 1993.
[8] "General Function of Messages and Signals of the ISDN User
Part of Signalling System No. 7", ITU-T Recommendation Q.762;
Mar. 1993.
[9] "Formats and Codes of the ISDN User Part of Signalling System
No. 7", ITU-T Recommendation Q.763; Mar. 1993.
[10] "Formats and Codes of the ISDN User Part of Signalling
System No. 7, ISDN User Part Signalling Procedures", ITU-T
Recommendation Q.764; Mar. 1993.
4. Security Considerations
This document introduces no new security considerations beyond
those already discussed in the referenced documents.
5. Author's Address
Adam Roach
Ericsson Inc.
Mailstop L-04
851 International Pkwy.
Richardson, TX 75081
USA
Phone: 972-583-7594
Fax: 972-669-0154
E-Mail: adam.roach@ericsson.com
Roach [Page 4]