rfc3372.txt

RFC 的详细文档！

                         <--18x

   2.  Support for ISUP is preferred.  UA2 does not support the ISUP and
       rejects the INVITE with a 415 Unsupported Media Type.  UA1 strips
       off the ISUP and re-sends the INVITE with SDP only and this is
       the accepted.

   UA1                    UA2
   INVITE--> (Content-type:multipart/mixed;
      Content-type: application/sdp;
      Content-disposition: session; handling=required;
      Content-type: application/isup;
      Content-disposition: signal; handling=required;)


                           <--415
                     (Accept: application/sdp)

   ACK-->

   INVITE-->
   (Content-type: application/sdp)

                           <--18x

   3.  Support for ISUP is mandatory for call establishment.  UA2 does
       not support the ISUP and rejects the INVITE with a 415
       Unsupported Media type.  UA1 then directs its request to UA3.












Vemuri & Peterson        Best Current Practice                 [Page 18]

RFC 3372                         SIP-T                    September 2002


   UA1                    UA2
   INVITE--> (Content-type:multipart/mixed;
      Content-type: application/sdp;
      Content-disposition: session; handling=required;
      Content-type: application/isup;
      Content-disposition: signal; handling=required;)

                        <--415
                  (Accept: application/sdp)

   ACK-->

   UA1                   UA3
   INVITE--> (Content-type:multipart/mixed;
       Content-type: application/sdp;
       Content-disposition: session; handling=required;
       Content-type: application/isup;
       Content-disposition: signal; handling=required;)

   Note that the exchanges of messages above are not complete; only the
   messages relevant to this discussion are shown.  Specifics of the
   ISUP MIME type can be obtained from [2].  The 'version' and 'base'
   parameters are not shown here, but must be used in accordance with
   the rules of [2].

7. Security Considerations

   SIP-T can be employed as an interdomain signaling mechanism that may
   be subject to pre-existing trust relationships between administrative
   domains.  In many legal environments, distribution of ISUP is
   restricted to licensed carriers; SIP-T introduces some challenges in
   so far as it bridges carrier signaling with end-user signaling.  Any
   administrative domain implementing SIP-T should have an adequate
   security apparatus (including elements that manage any appropriate
   policies to manage fraud and billing in an interdomain environment)
   in place to ensure that the transmission of ISUP information does not
   result in any security violations.

   Transporting ISUP in SIP bodies may provide opportunities for abuse,
   fraud, and privacy concerns, especially when SIP-T requests can be
   generated, inspected or modified by arbitrary SIP endpoints.  ISUP
   MIME bodies should be secured (preferably with S/MIME [4]) to
   alleviate this concern, as is described in the Security
   Considerations of the core SIP specification [1].  Authentication
   properties provided by S/MIME would allow the recipient of a SIP-T
   message to ensure that the ISUP MIME body was generated by an





Vemuri & Peterson        Best Current Practice                 [Page 19]

RFC 3372                         SIP-T                    September 2002


   authorized entity.  Encryption would ensure that only carriers
   possessing a particular decryption key are capable of inspecting
   encapsulated ISUP MIME bodies in a SIP request.

   SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and
   SHOULD support encryption (CMS EnvelopedData).

8. IANA Considerations

   This document introduces no new considerations for IANA.

Normative 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, May 2002.

   [2]   Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
         Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
         objects", RFC 3204, December 2001.

   [3]   Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [4]   Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
         2633, June 1999.

   [5]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

Non-Normative References

   [6]   International Telecommunications Union, "Signaling System No.
         7; ISDN User Part Signaling procedures", ITU-T Q.764, September
         1997, <http://www.itu.int>.

   [7]   Faltstrom, P., "E.164 number and DNS", RFC 2916, September
         2000.

   [8]   Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing
         over IP (TRIP)", RFC 3219, January 2002.

   [9]   Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
         Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [10]  Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP
         Mapping",  Work in Progress.





Vemuri & Peterson        Best Current Practice                 [Page 20]

RFC 3372                         SIP-T                    September 2002


   [11]  Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of
         ISUP Overlap Signaling to SIP", Work in Progress.

















































Vemuri & Peterson        Best Current Practice                 [Page 21]

RFC 3372                         SIP-T                    September 2002


Appendix A. Notes

   1.  Some terminating MGCs may alter the encapsulated ISUP in order to
       remove any conditions specific to the originating circuit; for
       example, continuity test flags in the Nature of Connection
       Indicators, etc.

   2.  Even so, the relevance of ANSI-specific information in an ETSI
       network (or vice versa) is questionable.  Clearly, the strength
       of SIP-T is realized when the encapsulated ISUP involves the
       usage of proprietary parameters.

Appendix B. Acknowledgments

   We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan
   Rosenberg, Dean Willis, Robert F.  Penfield, Steve Donovan, Allison
   Mankin, Scott Bradner and Steve Bellovin for their valuable comments.

   The original 'SIP+' proposal for interconnecting portions of the PSTN
   with SIP bridging was developed by Eric Zimmerer.

Authors' Addresses

   Aparna Vemuri-Pattisam
   Qwest Communications
   6000 Parkwood Pl
   Dublin, OH  43016 US
   EMail: [e-mail]
          [e-mail]

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520 US
   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.neustar.biz/













Vemuri & Peterson        Best Current Practice                 [Page 22]

RFC 3372                         SIP-T                    September 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Vemuri & Peterson        Best Current Practice                 [Page 23]