Reason Header in Responses             June 2007 
 
 
   BLISS                                                  Roland Jesske 
   Internet Draft                                      Deutsche Telekom 
   Intended Status: private                                                  
   Document: draft-jesske-sipping-etsi-ngn-reason-01.txt                    
   
   Expires: December 2007                                     June 2007 
    
    
    
    Use of the Reason header field in Session Initiation Protocol (SIP) 
                                 responses  
                draft-jesske-sipping-etsi-ngn-reason-01.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 December 6, 2007. 
    
   Copyright Notice 
    
   Copyright (C) The IETF Trust (2007). 
     
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 - December 2007               [Page 1] 
                      Reason Header in Responses             June 2007 
 
 
    
    
    
    
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. 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 in draft-jesske-sipping-tispan-
   requirements [5]]  
 
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 - December 2007               [Page 2] 
                      Reason Header in Responses             June 2007 
 
 
   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]  
    
        
3. Terminology  
     
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119. [9]. 
    
4. Procedures  
     
   For providing services and PSTN/ISDN interoperability for SIP 
   networks it MUST be possible to include Reason header fields with 
   Q.850 Cause values in responses.  
     
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 PSTN/ISDN like services foreseen.  
   For a pure SIP UA the reason header will not harm if not supported 
   because it will not be processed. For SIP end devices the support of 
   the Reason header field the cause maybe an valuable hint why the call 
   was released by an non SIP entity.  
     
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.3 Procedures 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 - December 2007               [Page 3] 
                      Reason Header in Responses             June 2007 
 
 
   For Example the application server could use the reason for sending a 
   announcement towards the originating entity of the Session.   
        
   If the application server provides a Service it can provide also 
   Responses include a Q.850 reason in responses.   
        
    
5. Procedures at an interworking point with ISUP 
   For interoperability reasons the Q.850 Cause Value 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: Example of an ISDN like service executed within the SIP 
   domain  
     
 
      Figure 2 shows the example of SIP interworking with the PSTN/ISDN 
   where the call is traversed through the SIP network 
        
        A                Gateway             Gateway              B  
        |        IAM        |                  |                  |  
        |------------------>|     INVITE       |                  |  
        |                   |----------------->|      IAM         |  
        |                   |     100 Trying   |----------------->|  
        |                   |                  |  REL Cause #29   |  
        |                   | 500 Server Error |                  |  
        |                   |  Reason Q850 #29 |                  |  
 
 
Jesske                 Expires - December 2007               [Page 4] 
                      Reason Header in Responses             June 2007 
 
 
        |   REL Cause #29   |                  |<-----------------|  
        |                   |<-----------------|                  |  
        |<----------------- |                  |                  |  
        |                   |                  |                  |  
        |                   |                  |                  |  
    
           Figure 1: Example of an ISDN - SIP - ISDN Call 
 
  
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 entities. 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 only by 
   trusted entities as it is described within RFC3325 [8] or at least by 
   network entities. 
  
 
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 Require- 
      ments 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-04.txt (work in progress), June 2007.  
        
   [4] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP 
      and SDP".  
        
 
 
Jesske                 Expires - December 2007               [Page 5] 
                      Reason Header in Responses             June 2007 
 
 
   [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) 
      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   
        
   [8] 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.  
        
Contributors   
     
   Denis Alexeitsev   
   Deutsche Telekom   
   Deutsche Telekom Allee1 
   64307 Darmstadt   
   Germany   
   Phone: +496151832130   
   Email: d.alexeitsev@t-com.net     
     
     
     
Acknowledgments   
     
   The author would like to thank the members of the ETSI TISPAN WG3  
   for their comments to this memo.  
      
  
Author's Addresses   
     
   Roland Jesske   
   Deutsche Telekom   
   Deutsche Telekom Allee1 
   64307 Darmstadt   
 
 
Jesske                 Expires - December 2007               [Page 6] 
                      Reason Header in Responses             June 2007 
 
 
   Germany   
   Phone: +496151835940   
   Email: r.jesske@t-com.net   
    
Full Copyright Statement 
 
   Copyright (C) The IETF Trust (2007). 
    
   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 
 
 
Jesske                 Expires - December 2007               [Page 7] 
                      Reason Header in Responses             June 2007 
 
 
   Administrative Support Activity (IASA). 
 
 
 













































 
 
Jesske                 Expires - December 2007               [Page 8]