RFC 4411 - Extending the Session Initiation Protocol (SIP) R(3)

时间:2006-11-02 来源: 作者: 点击:
7.1."Preemption"NamespaceRegistry RFC4411createsthenewSIP"ReasonHeader"[1]protocolnamespace: "Preemption",with4definedcausecodes: Ininstanceswherethisnamespaceisusedtoindicatepreemption ataUA,thefoll
  

7.1.  "Preemption" Namespace Registry

   RFC 4411 creates the new SIP "Reason Header" [1] protocol namespace:
   "Preemption", with 4 defined cause codes:

      In instances where this namespace is used to indicate preemption
      at a UA, the following syntax shall be used (the reason-text is a
      default string; it is not mandatory, and may be different):

         Reason: preemption ;cause=1 ;text="UA Preemption"

         Section 5.1 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for
         default text strings for any new protocol namespace cause code.
         See Section 7.2 for details.

      In instances where this namespace is used to indicate preemption
      because an RSVP ResvErr message was received at a SIP UA, the
      following syntax shall be used (the reason-text is a default
      string; it is not mandatory, and may be different):

      Reason: preemption ;cause=2 ;text="Reserved Resources Preempted"

         Section 5.2 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for
         default text strings for any new protocol namespace cause code.
         See section 7.2 for details.

      In instances where this namespace is used to indicate a
      generalized preemption event to the destination UA from a Proxy
      that modifies the Reason value only during this last SIP hop, the
      following syntax shall be used (the reason-text is a default
      string; it is not mandatory, and may be different):

         Reason: preemption ;cause=3 ;text="Generic Preemption"

         Section 5.3 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for
         default text strings for any new protocol namespace cause code.
         See Section 7.2 for details.

      In instances where this namespace is used to indicate preemption
      from a non-IP portion of a call leg, a SIP Gateway shall use the
      following syntax to inform the SIP infrastructure of this event
      (the reason-text is a default string; it is not mandatory, and may
      be different):

         Reason: preemption ;cause=4 ;text=" Non-IP Preemption"

         Section 5.4 of this document describes in detail the semantics
         of this cause code.

         The default text above is part of a new IANA Registry for
         default text strings for any new protocol namespace cause code.
         See Section 7.2 for details.

   Additional definitions of the preemption namespace and its cause
   codes MUST be defined in Standards Track documents.

7.2.  Default Reason-Text IANA Registry for the SIP Reason Header

   Below is a new IANA Registry for SIP Reason Header reason-text
   strings, associated with their respective protocol type and Reason-
   param cause values.  Per RFC 3326, the Reason-text string is a quoted
   default string with only human understandability meant.  These
   strings can be changed by local policy.

                Reason-
   Protocol     param      Reason-Text         Reference
   --------     -------    ------------        ---------
   Preemption   Cause=1    UA Preemption       RFC 4411
   Preemption   Cause=2    Reserved Resources  RFC 4411
                             Preempted
   Preemption   Cause=3    Generic Preemption  RFC 4411
   Preemption   Cause=4    Non-IP Preemption   RFC 4411

8.  Contributions

   The following individuals contributed to this effort:

      Subhasri Dhesikan
      Gonzalo Camarillo
      Dave Oran

   The author thanks these individuals greatly for their aid in this
   effort.

9.  Acknowledgements

   To Haluk Keskiner for providing a valued sanity check.  To Dean
   Willis, Rohan Mahy, and Allison Mankin for their belief in and
   backing of this effort.  To Adam Roach and Arun Kumar for helpful
   comments to this document.

   Thanks to Mike Pierce for helpful comments and catching a flaw in
   this spec late in the process (before it was too late).

10.  References

10.1.  Normative References

   [1] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
       Field for the Session Initiation Protocol (SIP)", RFC 3326,
       December 2002.

   [2] 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.

   [3] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
       Resource Management and Session Initiation Protocol (SIP)", RFC
       3312, October 2002.

   [4] Schulzrinne, H. and J. Polk, "Communications Resource-Priority
       Header in the Session Initiation Protocol (SIP)", RFC 4412,
       February 2006.

   [5] ITU-T Recommendation Q.850 (1993)

   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
       "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
       Specification", RFC 2205, September 1997.

10.2.  Informative References

   [8] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, "NSLP
       for Quality-of-Service signalling", Work in Progress, September
       2005.

Author Information

   James M. Polk
   Cisco Systems
   2200 East President George Bush Turnpike
   Richardson, Texas 75082 USA

   EMail: jmpolk@cisco.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容