rfc3372.txt

RFC 的详细文档！

   1.  The originators of SIP signaling

   2.  The terminators of SIP signaling

   3.  The intermediaries that route SIP requests from the originator to
       the terminator

   Behavior for the Section 4.1, Section 4.2 and Section 4.3
   intermediary roles in a SIP-T call are described in the following
   sections.

4.1 Originator

   The function of the originating user agent client is to generate the
   SIP Call setup requests (i.e., INVITEs).  When a call originates in
   the PSTN, a gateway is the UAC; otherwise some native SIP endpoint is
   the UAC.  In either case, note that the originator generally cannot
   anticipate what sort of entity the terminator will be, i.e., whether
   final destination of the request is in a SIP network or the PSTN.







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


   In the case of calls originating in the PSTN (see Figure 3 and Figure
   5), the originating gateway takes the necessary steps to preserve the
   ISUP information by encapsulating it in the SIP request it creates.
   The originating gateway is entrusted with the responsibility of
   identifying the version of the ISUP (ETSI, ANSI, etc.) that it has
   received and providing this information in the encapsulated ISUP
   (usually by adding a multipart MIME body with appropriate MIME
   headers).  It then formulates the headers of the SIP INVITE request
   from the parameters of the ISUP that it has received from the PSTN as
   appropriate (see Section 5).  This might, for instance, entail
   setting the 'To:' header field in the INVITE to the reflect dialed
   number (Called Party Number) of the received ISUP IAM.

   In other cases (like Figure 7), a SIP phone is the originator of a
   VoIP call.  Usually, the SIP phone sends requests to a SIP proxy that
   is responsible for routing the request to an appropriate destination.
   There is no ISUP to encapsulate at the user agent client, as there is
   no PSTN interface.  Although the call may terminate in the telephone
   network and need to signal ISUP in order for that to take place, the
   originator has no way to anticipate this and it would be foolhardy to
   require that all SIP VoIP user agents have the capability to generate
   ISUP.  It is therefore not the responsibility of an IP endpoints like
   a SIP phone to generate encapsulated ISUP.  Thus, an originator must
   generate the SIP signaling while performing ISUP encapsulation and
   translation when possible (meaning when the call has originated in
   the PSTN).

   Originator requirements: encapsulate ISUP, translate information from
   ISUP to SIP, multipart MIME support (for gateways only)

4.2 Terminator

   The SIP-T terminator is a consumer of the SIP calls.  The terminator
   is a standard SIP UA that can be either a gateway that interworks
   with the PSTN or a SIP phone.
















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


   In case of PSTN terminations (see Figure 3 and Figure 7) the egress
   gateway terminates the call to its PSTN interface.  The terminator
   generates the ISUP appropriate for signaling to the PSTN from the
   incoming SIP message.  Values for certain ISUP parameters may be
   gleaned from the SIP headers or extracted directly from an
   encapsulated ISUP body.  Generally speaking, a gateway uses any
   encapsulated ISUP as a template for the message it will send, but it
   overwrites parameter values in the template as it translates SIP
   headers or adds any parameter values that reflect its local policies
   (see Appendix A item 1).

   In case of an IP termination (Figure 5), the SIP UAS that receives
   SIP messages with encapsulated ISUP typically disregards the ISUP
   message.  This does introduce a general requirement, however, that
   devices like SIP phones handle multipart MIME messages and unknown
   MIME types gracefully (this is a baseline SIP requirement, but also a
   place where vendors have been known to make shortcuts).

   Terminator requirements: standard SIP processing, interpretation of
   encapsulated ISUP (for gateways only), support for multipart MIME,
   graceful handling of unknown MIME content (for non-gateways only)

4.3 Intermediary

   Intermediaries like proxy servers are entrusted with the task of
   routing messages to one another, as well as gateways and SIP phones.
   Each proxy server makes a forwarding decision for a SIP request based
   on values of various headers, or 'routable elements' (including the
   Request-URI, route headers, and potentially many other elements of a
   SIP request).

   SIP-T does introduce some additional considerations for forwarding a
   request that could lead to new features and requirements for
   intermediaries.  Feature transparency of ISUP is central to the
   notion of SIP-T.  Compatibility between the ISUP variants of the
   originating and terminating PSTN interfaces automatically leads to
   feature transparency.  Thus, proxy servers might take an interest in
   the variants of ISUP that are encapsulated with requests - the
   variant itself could become a routable element.  The termination of a
   call at a point that results in greater proximity to the final
   destination (rate considerations) is also an important consideration.
   The preference of one over the other results in a trade-off between
   simplicity of operation and cost.  The requirement of procuring a
   reasonable rate may dictate that a SIP-T call spans dissimilar PSTN
   interfaces (SIP bridging across different gateways that don't support
   any ISUP variants in common).  In order to optimize for maximum
   feature transparency and rate, some operators of intermediaries might
   want to consider practices along the following lines:



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


   a) The need for ISUP feature transparency may necessitate ISUP
      variant translation (conversion), i.e., conversion from one
      variant of ISUP to another in order to facilitate the termination
      of that call over a gateway interface that does not support the
      ISUP variant of the originating PSTN interface.  (See Appendix A
      item 2.) Although in theory conversion may be performed at any
      point in the path of the request, it is optimal to perform it at a
      point that is at the greatest proximity to the terminating
      gateway.  This could be accomplished by delivering the call to an
      application that might perform the conversion between variants.
      Feature transparency in this case is contingent on the
      availability of resources to perform ISUP conversion, and it
      incurs an increase in the call-set up time.

   b) An alternative would be to sacrifice ISUP transparency by handing
      the call off to a gateway that does not support the version of the
      originating ISUP.  The terminating MGC would then just ignore the
      encapsulated ISUP and use the information in the SIP header to
      terminate the call.

   So, it may be desirable for proxy servers to have the intelligence to
   make a judicious choice given the options available to it.

   Proxy requirements: ability to route based on choice of routable
   elements

4.4 Behavioral Requirements Summary

   If the SIP-T originator is a gateway that received an ISUP request,
   it must always perform both encapsulation and translation ISUP,
   regardless of where the originator might guess that the request will
   terminate.

   If the terminator does not understand ISUP, it ignores it while
   performing standard SIP processing.  If the terminator does
   understand ISUP, and needs to signal to the PSTN, it should reuse the
   encapsulated ISUP if it understands the variant.  The terminator
   should perform the following steps:

   o  Extract the ISUP from the message body, and use this ISUP as a
      message template.  Note that if there is no encapsulated ISUP in
      the message, the gateway should use a canonical template for the
      message type in question (a pre-populated ISUP message configured
      in the gateway) instead.







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


   o  Translate the headers of the SIP request into ISUP parameters,
      overwriting any values in the message template.

   o  Apply any local policies in populating parameters.

   An intermediary must be able to route a call based on the choice of
   routable elements in the SIP headers.

5. Components of the SIP-T Protocol

   The mechanisms described in the following sections are the components
   of SIP-T that provide the protocol functions entailed by the
   requirements.

5.1 Core SIP

   SIP-T uses the methods and procedures of SIP as defined by RFC 3261.

5.2 Encapsulation

   Encapsulation of the PSTN signaling is one of the major requirements
   of SIP-T.  SIP-T uses multipart MIME bodies to enable SIP messages to
   contain multiple payloads (Session Description Protocol or SDP [5],
   ISUP, etc.).  Numerous ISUP variants are in existence today; the ISUP
   MIME type enable recipients too recognize the ISUP type (and thus
   determine whether or not they support the variant) in the most
   expeditious possible manner.  One scheme for performing ISUP
   encapsulation using multi-part MIME has been described in [2].

5.3 Translation

   Translation encompasses all aspects of signaling protocol conversion
   between SIP and ISUP.  There are essentially two components to the
   problem of translation:

   1.  ISUP SIP message mapping:  This describes a mapping between ISUP
       and SIP at the message level.  In SIP-T deployments gateways are
       entrusted with the task of generating a specific ISUP message for
       each SIP message received and vice versa.  It is necessary to
       specify the rules that govern the mapping between ISUP and SIP
       messages (i.e., what ISUP messages is sent when a particular SIP
       message is received: an IAM must be sent on receipt of an INVITE,
       a REL for BYE, and so on).  A potential mapping between ISUP and
       SIP messages has been described in [10].







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


   2.  ISUP parameter-SIP header mapping:  A SIP request that is used to
       set up a telephone call should contain information that enables
       it to be appropriately routed to its destination by proxy servers
       in the SIP network - for example, the telephone number dialed by
       the originating user.  It is important to standardize a set of
       practices that defines the procedure for translation of
       information from ISUP to SIP (for example, the Called Party
       Number in an ISUP IAM must be mapped onto the SIP 'To' header
       field and Request-URI, etc.).  This issue becomes inherently more
       complicated by virtue of the fact that the headers of a SIP
       request (especially an INVITE) may be transformed by
       intermediaries, and that consequently, the SIP headers and
       encapsulated ISUP bodies come to express conflicting values -
       effectively, a part of the encapsulated ISUP may be rendered
       irrelevant and obsolete.

5.4 Support for mid-call signaling

   Pure SIP does not have any provision for carrying any mid-call
   control information that is generated during a session.  The INFO [3]
   method should be used for this purpose.  Note however that INFO is
   not suitable for managing overlap dialing (for one way of
   implementing overlap dialing see [11]).  Also note that the use of
   INFO for signaling mid-call DTMF signals is not recommended (see
   RFC2833 [9] for a recommended mechanism).

6. SIP Content Negotiation

   The originator of a SIP-T request might package both SDP and ISUP
   elements into the same SIP message by using the MIME multipart
   format.  Traditionally in SIP, if the terminating device does not
   support a multipart payload (multipart/mixed) and/or the ISUP MIME
   type, it would then reject the SIP request with a 415 Unsupported
   Media Type specifying the media types it supports (by default,
   'application/SDP').  The originator would subsequently have to re-
   send the SIP request after stripping out the ISUP payload (i.e.  with
   only the SDP payload) and this would then be accepted.

   This is a rather cumbersome flow, and it is thus highly desirable to
   have a mechanism by which the originator could signify which bodies
   are required and which are optional so that the terminator can
   silently discard optional bodies that it does not understand
   (allowing a SIP phone to ignore an ISUP payload when processing ISUP
   is not critical).  This is contingent upon the terminator having
   support for a Content-type of multipart/mixed and access to the
   Content-Disposition header to express criticality.





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


   1.  Support for ISUP is optional.  Therefore, UA2 accepts the INVITE
       irrespective of whether it can process the ISUP.

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