rfc2848.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   network identified by +97252 is the string "123". It so happens that
   +97252 defines one of the Israeli cell phone providers, and 123
   reaches customer service when dialled within that network.

   It may well be useful or necessary to use the SDP "require" parameter
   in conjunction with the phone-context attribute.

   Example 4:

         c= TN  RFC2543  321
         a=phone-context:X-acme.com-23

   This might describe the telephone terminal that is at extension 321
   of PBX number 23 within the acme.com private PBX network. It is
   expected that such a description would be understandable by the
   acme.com PINT server that receives the request.

   Note that if the PINT server receiving the request is inside the
   acme.com network, the same terminal might be addressable as follows:

         c= TN  RFC2543 7-23-321

   (assuming that "7" is dialled in order to reach the private PBX
   network from within acme.com)

3.4.3.2. Presentation Restriction attribute

   Although it has no affect on the transport of the service request
   through the IP Network, there may be a requirement to allow
   originators of a PINT service request to indicate whether or not they
   wish the "B party" in the resulting service call to be presented with
   the "A party's" calling telephone number. It is a legal requirement
   in some jurisdictions that a caller be able to select whether or not
   their correspondent can find out the calling telephone number (using
   Automatic Number Indication or Caller Display or Calling Line
   Identity Presentation equipment). Thus an attribute may be needed to
   indicate the originator's preference.

   Whether or not the default behaviour of the Executive System is to
   present or not present a party's telephone number to the
   correspondent GSTN terminal is not specified, and it is not mandatory
   in all territories for a PINT Gateway or Executive System to act on



Petrack & Conroy            Standards Track                    [Page 22]

RFC 2848               The PINT Service Protocol               June 2000


   this attribute. It is, however, defined here for use where there are
   regulatory restrictions on GSTN operation, and in that case the
   Executive System can use it to honour the originator's request.

   The attribute is specified as follows:
       a=clir:<"true" | "false">

   This boolean value is needed within the attribute as it may be that
   the GSTN address is, by default, set to NOT present its identity to
   correspondents, and the originator wants to do so for this particular
   call. It is in keeping with the aim of this attribute to allow the
   originator to specify what treatment they want for the requested
   service call.

   The expected interpretation of this attribute is that, if it is
   present and the value is "false" then the Calling Line Identity CAN
   be presented to the correspondent terminal, whilst if it is "true"
   then if possible the Executive System is requested to NOT present the
   Calling Line Identity.

3.4.3.3. ITU-T CalledPartyAddress attributes parameters

   These attributes correspond to fields that appear within the ITU-T
   Q.763 "CalledPartyAddress" field (see [8] ,section 3.9). PINT clients
   use these attributes in order to specify further parameters relating
   to Terminal Addresses, in the case when the address indicates a
   "local-phone-number". In the case that the PINT request contains a
   reference to a GSTN terminal, the parameters may be required to
   correctly identify that remote terminal.

   The general form of this attribute is:  "a=Q763-<token>((":" <value>)
   |"")".  Three of the possible elements and their use in SDP
   attributes are described here. Where other Q763 elements are to be
   used, then these should be the subject of further specification to
   define the syntax of the attribute mapping. It is recommended that
   any such specification maintains the value sets shown in Q.763.

   The defined attributes are:

   a=Q763-nature:  - indicates the "nature of address indicator".
                       The value MAY be any number between 0 and 127.
                       The following values are specified:

                   "1" a subscriber number
                   "2" unknown
                   "3" a nationally significant number
                   "4" an internationally significant number




Petrack & Conroy            Standards Track                    [Page 23]

RFC 2848               The PINT Service Protocol               June 2000


   The values have been chosen to coincide with the values in Q.763.
   Note that other values are possible, according to national rules or
   future expansion of Q.763.

   a=Q763-plan:    - indicates the numbering plan to which the address
                       belongs. The value MAY be any number between 0
                       and 7. The following values are specified:

                   "1" Telephone numbering plan (ITU-T E.164)
                   "3" Data numbering plan (ITU-T X.121)
                   "4" Telex numbering plan (ITU-T F.69)

   The values have been chosen to coincide with the values in Q.763.
   Other values are allowed, according to national rules or future
   expansion of Q.763.

   a=Q763-INN      - indicates if routing to the Internal Network Number
                       is allowed. The value MUST be ONE of:

                   "0" routing to internal network number allowed
                   "1" routing to internal network number not
                                 allowed

   The values have been chosen to coincide with the values in Q.763.
   Note that it is possible to use a local-phone-number and indicate via
   attributes that the number is in fact an internationally significant
   E.164 number. Normally this SHOULD NOT be done; an internationally
   significant E.164 number is indicated by using a "global-phone-
   number" for the address string.

3.4.4. The "require" attribute

   According to the SDP specification, a PINT server is allowed simply
   to ignore attribute parameters that it does not understand. In order
   to force a server to decline a request if it does not understand one
   of the PINT attributes, a client SHOULD use the "require" attribute,
   specified as follows:

         a=require:<attribute-list>

   where the attribute-list is a comma-separated list of attributes that
   appear elsewhere in the session description.

   In order to process the request successfully the PINT server must
   BOTH understand the attribute AND ALSO fulfill the request implied by
   the presence of the attribute, for each attribute appearing within
   the attribute-list of the require attribute.




Petrack & Conroy            Standards Track                    [Page 24]

RFC 2848               The PINT Service Protocol               June 2000


   If the server does not recognise the attribute listed, the PINT
   server MUST return an error status code (such as 420 (Bad Extension)
   or 400 (Bad Request)), and SHOULD return suitable Warning: lines
   explaining the problem or an Unsupported: header containing the
   attribute it does not understand. If the server recognizes the
   attribute listed, but cannot fulfill the request implied by the
   presence of the attribute, the request MUST be rejected with a status
   code of (606 Not Acceptable), along with a suitable Unsupported:
   header or Warning: line.

   The "require" attribute may appear anywhere in the session
   description, and any number of times, but it MUST appear before the
   use of the attribute marked as required.

   Since the "require" attribute is itself an attribute, the SIP
   specification allows a server that does not understand the require
   attribute to ignore it. In order to ensure that the PINT server will
   comply with the "require" attribute, a PINT client SHOULD include a
   Require: header with the tag "org.ietf.sdp.require" (section 3.5.4)

   Note that the majority of the PINT extensions are "tagged" and these
   tags can be included in Require strictures. The exception is the use
   of phone numbers in SDP parts. However, these are defined as a new
   network and address type, so that a receiving SIP/SDP server should
   be able to detect whether or not it supports these forms. The default
   behaviour for any SDP recipient is that it will fail a PINT request
   if it does not recognise or support the TN and RFC2543 or X-token
   network and address types, as without the contents being recognised
   no media session could be created. Thus a separate stricture is not
   required in this case.

3.5. PINT Extensions to SIP 2.0

   PINT requests are SIP requests; Many of the specifications within
   this document merely explain how to use existing SIP facilities for
   the purposes of PINT.

3.5.1. Multi-part MIME (sending data along with SIP request)

   A PINT request can contain a payload which is multipart MIME. In this
   case the first part MUST contain an SDP session description that
   includes at least one of the format specific attribute tags for
   "included content data" specified above in section 3.4.3. Subsequent
   parts contain content data that may be transferred to the requested
   Telephone Call Service. As discussed earlier, within a single PINT
   request, some of the data MAY be pointed to by a URI within the
   request, and some of the data MAY be included within the request.




Petrack & Conroy            Standards Track                    [Page 25]

RFC 2848               The PINT Service Protocol               June 2000


   Where included data is carried within a PINT service request, the
   Content Type entity header of the enclosing SIP message MUST indicate
   this. To do so, the media type value within this entity header MUST
   be set to a value of "multipart". There is a content sub-type that is
   intended for situations like this in which sub-parts are to be
   handled together. This is the multipart/related type (defined in
   [19]), and it's use is recommended.

   The enclosed body parts SHOULD include the part-specific Content Type
   headers as appropriate ("application/sdp" for the first body part
   holding the session description, with an appropriate content type for
   each of the subsequent, "included data object" parts). This matches
   the standard syntax of MIME multipart messages as defined in [4].

   For example, in a multipart message where the string

   "------next-------" is the boundary, the first two parts might be as
   follows:

         ------next-------
         Content-Type: application/sdp
         ....
         c= TN RFC2543 [phone]
         m= text 1 pager plain
         a=fmtp:plain spr:[e-mail]

         ----------next-------
         Content-Type: text/plain
         Content-ID:  [e-mail]

         This is the text that is to be paged to [phone]

         ----------next-----------

   The ability to indicate different alternatives for the content to be
   transported is useful, even when the alternatives are included within
   the request. For example, a request to send a short message to a
   pager might include the message in Unicode [5] and an alternative
   version of the same content in text/plain, should the PINT server or
   telephone network not be able to process the unicode.

   PINT clients should be extremely careful when sending included data
   within a PINT request. Such requests SHOULD be sent via TCP, to avoid
   fragmentation and to transmit the data reliably. It is possible that
   the PINT server is a proxy server that will replicate and fork the
   request, which could be disastrous if the request contains a large
   amount of application data. PINT proxy servers should be careful not
   to create many copies of a request with large amounts of data in it.



Petrack & Conroy            Standards Track                    [Page 26]

RFC 2848               The PINT Service Protocol               June 2000


   If the client does not know the actual location of the PINT gateway,
   and is using the SIP location services to find it, and the included
   data makes the PINT request likely to be transported in several IP
   datagrams, it is RECOMMENDED that the initial PINT request not
   include the data object but instead hold a reference to it.

3.5.2. Warning header

   A PINT server MUST support the SIP "Warning:" header so that it can
   signal lack of support for individual PINT features. As an example,
   suppose the PINT request is to send a jpeg picture to a fax machine,
   but the server cannot retrieve and/or translate jpeg pictures from
   the Internet into fax transmissions.

   In such a case the server fails the request and includes a Warning
   such as the following:

         Warning:  305  pint.acme.com  Incompatible media format:  jpeg

   SIP servers that do not underst