One document matched: draft-jesske-sipping-etsi-ngn-reason-02.txt
Differences from draft-jesske-sipping-etsi-ngn-reason-01.txt
Internet-Draft Reason Header in Responses January 2008
SIPPING Roland Jesske
INTERNET-DRAFT Deutsche Telekom
Intended Status: Informational
Document:
draft-jesske-sipping-etsi-ngn-reason-02.txt
Expires: July 9, 2008 January 8, 2008
Use of the Reason header filed in Session Initiation Protocol (SIP)
responses
draft-jesske-sipping-etsi-ngn-reason-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on July 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document proposes the use of the Reason header field in SIP
responses. In addition for the interoperability wit DSS1 interworked
devices and the ISUP a Location fild is defined in addition.
Jesske Expires - July 2008 [Page 1]
Internet-Draft Reason Header in Responses January 2008
Table of Contents
1. Overview.......................................................2
2. Overall Applicability..........................................2
3. Terminology....................................................3
4. Procedures.....................................................3
4.1 Procedures at the UA.......................................3
4.2 Procedures at a SIP proxy..................................3
4.3 Procedures at an application server........................3
5. Procedures at an interworking point with ISUP..................4
6. Example........................................................4
7. Security Considerations........................................5
8. IANA Considerations............................................5
9. References.....................................................5
1.
Overview
The European Telecommunication Standards Institute (ETSI) is defining
a Next Generation Network (NGN) where a substantial part of it is
based on the IP Multimedia Subsystem (IMS) defined by the Third-
Generation Partnership Project (3GPP). IMS is largely based on the
Session Initiation Protocol [1].
ETSI has developed a number of requirements draft-jesske-sipping-
tispan-requirements [5] to support the usage of SIP in Next
Generation Networks that interoperate, at the service level, with the
Public Switched Telephone Network (PSTN), the Integrated Services
Digital Network (ISDN), the 3GPP IP Multimedia Subsystem (IMS), and
SIP networks and terminals that implement the service logic.
In order to provide full support in SIP of existing services,
extensions to SIP are needed.
This document proposes the use of the Reason header field in
responses and adds a location field where the release was originated.
This is needed for creating services that must be interoperable with
the PSTN/ISDN network and the interoperability of traversing
communications through SIP not using SIP-I. This fulfils the
requirement [REQ-GEN-1]
2.
Overall Applicability
The SIP procedures specified in this document are foreseen for
networks providing simulation services and/or interworking to the
PSTN/ISDN.
Jesske Expires - July 2008 [Page 2]
Internet-Draft Reason Header in Responses January 2008
The document is describing the use of the Reason header in SIP
responses. These procedures are only valuable if the reason contained
in the element "protocol" is "Q.850". A inclusion of a SIP reason
(protocol="SIP") is not helpful due to the fact that the response
already provides the SIP reason. The Release Causes are described
within ETSI EN300 485 [5]
To provide more information to ISDN devices that are using SIP UA's
like a IAD (Integrated Access Devices) as relay for interworking the
release location of the call should be included within the Reason
Header. Such information is meaningful for scenarios where the user
phones to an ISUP network.
3.
Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in RFC 2119
[RFC2119].
4.
Procedures
For providing services and PSTN/ISDN interoperability it MUST be
possible to include Reason header fields with Q.850 Cause values.
4.1
Procedures at the UA
A UA that supports the Reason header field can process the Q.850
Cause Value and display it or an equivalent text. The inclusion of a
Reason header field by UA is only for 2B2 UA interworking with the
PSTN/ISDN or providing services foreseen.
4.2
Procedures at a SIP proxy
SIP proxies that receive a response containing a Reason header field
is forwarding the response without changing the reason.
A SIP proxy receiving a request that includes a Reason header field
can route the request to an application server for further analysis
and base services on it.
Based on network policy a Proxy can remove a Reason header field send
from a UAC.
4.3P
rocedures at an application server
An application server that receives a SIP request that contains a
response including a Reason header MAY analyze the SIP Reason and
base further procedures on this analyses.
Jesske Expires - July 2008 [Page 3]
Internet-Draft Reason Header in Responses January 2008
For Example the application server could use the reason for sending a
announcement towards the originating entity of the Session.
As an example the Anonymous Communication Rejection (ACR) service
defined by ETSI Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN)
5.
Procedures at an interworking point with ISUP
For interoperability reasons the Q.850 Cause Value and the Location
of a Release shall be mapped to the Reason Header.
6.
Example
Figure 1 shows the example of SIP interworking with the PSTN/ISDN
A Gateway Proxy AS
| IAM | | |
|------------------>| INVITE | |
| |----------------->| INVITE |
| | 100 Trying |----------------->|
| |<-----------------| 100 Trying |
| | |<-----------------|
| ACK SDP held | | |
|<------------------| | 603 Decline |
| | 603 Decline | Reason Q850 #87 |
| | Reason Q850 #87 | |
| REL Cause #87 | |<-----------------|
| |<-----------------| |
|<----------------- | | |
| | | |
| | | |
| | | |
Figure 1: ISUP-SIP Call
Figure 2 shows the example where the SIP network is used as
transit between PSTN/ISDN networks
A Gateway Gateway B
| IAM | | |
|------------------>| INVITE | |
| |----------------->| IAM |
| | 100 Trying |----------------->|
| |<-----------------| 100 Trying |
| | 603 Decline | |
| | Reason Q850 #87 | REL Cause #87 |
| REL Cause #87 | |<-----------------|
| |<-----------------| |
|<----------------- | | |
Jesske Expires - July 2008 [Page 4]
Internet-Draft Reason Header in Responses January 2008
| | | |
| | | |
| | | |
Figure 2: Transit case
7.
Security Considerations
The presence of the Reason header in a response does not affect the
treatment of the response.
Including such a header by an untrusted entity could adulterate the
reactions of the originating entitys. E.G. sending back a cause value
"87" can cause an announcement within the PSTN/ISDN saying that the
call was rejected due to the Closed User Group service.
Therefore it is RECOMMENDED to include the Reason header including
the location information in Responses only by trusted entities as it
is described within RFC3325 [7]
8.
IANA Considerations
This document describes the use of the Reason header field described
within RFC 3326 [2]. No additional SIP elements are defined within
this document. Therefore, this document does not provide any action
to IANA.
9.
References
[1] 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.
[2] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the
Session Initiation Protocol (SIP)", RFC 3326.
[3] Jesske, R., Alexeitsev, D., Garcia-Martin, M. "Input
Requirements for the Session Initiation Protocol (SIP) in support
for the European Telecommunications Standards Institute (ETSI)
Next Generation Network (NGN) simulation services", draft-jesske-
sipping-tispan-requirements-03.txt (work in progress), June 2005.
[4] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP
and SDP".
[5] ETSI EN 300 485: "Integrated Services Digital Network (ISDN);
Dfinition and usage of cause and location in Digital Subscriber
Signalling System No. one (DSS1) and Signalling System No. 7 (SS7)
Jesske Expires - July 2008 [Page 5]
Internet-Draft Reason Header in Responses January 2008
ISDN User Part (ISUP) [ITU-T Recommendation Q.850 (1998) with
addendum modified] ".
[6] Jesske, R., Alexeitsev, D., Garcia-Martin, M. "Analysis of the
Input Requirements for the Session Initiation Protocol (SIP) in
support for the European Telecommunications Standards Institute
(ETSI) Next Generation Networks (NGN) simulation services" (work
in progress) June 2005
[7] Jennings C., Peterson J., and Watson M. "Private Extensions to
the Session Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325, November 2002.
[9] RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997 (TXT, HTML,
XML).
Note: The ETSI specifications can be downloaded under
http://pda.etsi.org/pda/queryform.asp free of charge.
10.
Contributors
Denis Alexeitsev
Deutsche Telekom
Deutsche Telekom Allee1
64307 Darmstadt
Germany
Phone: +496151832130
Email: d.alexeitsev@t-com.net
11.
Acknowledgments
The author would like to thank the members of the ETSI TISPAN WG3 for
their comments to this memo.
12.
Author's Address
Roland Jesske
Deutsche Telekom
Deutsche Telekom Allee1
64307 Darmstadt
Germany
Phone: +496151835940
Email: r.jesske@t-com.net
Jesske Expires - July 2008 [Page 6]
Internet-Draft Reason Header in Responses January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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 procedures with respect to rights in RFC 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jesske Expires - July 2008 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 02:01:01 |