rfc2848.txt

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

   where URI-reference is as defined in Appendix A of [9]





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


   For example:

         c= TN RFC2543 [phone]
         m= text 1  fax plain
         a=fmtp:plain  uri:ftp://ftp.isi.edu/in-notes/rfc2468.txt
   or:
         c= TN RFC2543 [phone]
         m= text 1  fax plain
         a=fmtp:plain
   uri:http://www.ietf.org/meetings/glance_minneapolis.txt

   means get this data object from the Internet and use it as a source
   for the requested GSTN Fax service.

3.4.2.3. Support for GSTN-based Data Objects in PINT

   PINT services may refer to data that are held not on the IP Network
   but instead within the GSTN. The way in which these items are
   indicated need have no meaning within the context of the Requestor or
   the PINT Gateway; the reference is merely some data that may be used
   by the Executive System to indicate the content intended as part of
   the request. These data form an opaque reference, in that they are
   sent "untouched" through the PINT infrastructure.

   A reference to some data object held on the GSTN has the general
   definition:

       <opaque-ref> := ("opr:" *uric)

   where uric is as defined in Appendix A of [9].

   For example:

         c= TN RFC2543 [phone]
         m= text 1  fax plain
         a=fmtp:plain  opr:APPL.123.456

   means send the data that is indexed ON THE GSTN by the reference
   value "APPL.123.456" to the fax machine on [phone]. The
   Executive System may also take the Telephone URL held in the To:
   field of the enclosing SIP message into account when deciding the
   context to be used for the data object dereference.

   Of course, an opaque reference may also be used for other purposes;
   it could, for example, be needed to authorise access to a document
   held on the GSTN rather than being required merely to disambiguate





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


   the data object. The purpose to which an opaque reference is put,
   however, is out of scope for this document. It is merely an indicator
   carried within a PINT Request.

   An opaque reference may have no value in the case where the value to
   be used is implicit in the rest of the request. For example, suppose
   some company wishes to use PINT to implement a "fax-back service". In
   their current implementation, the image(s) to be faxed are entirely
   defined by the telephone number dialled. Within the PINT request,
   this telephone number would appear within the "To:" field of the PINT
   request, and so there is no need for an opaque reference value.

   If there are several resolutions for a PINT Service Request, and one
   of these is an opaque reference with no value, then that opaque
   reference MUST be included in the attribute line, but with an empty
   value field.

   For example:

         c= TN RFC2543 [phone]
         m= text 1  fax plain
         a=fmtp:plain  uri:http://www.sun.com/index.html opr:

   might be used to precede some data to be faxed with a covering note.

   In the special case where an opaque reference is the sole resolution
   of a PINT Service Request, AND that reference needs no value, there
   is no need for a Fmt list at all; the intent of the service is
   unambiguous without any further resolution.

   For example:

         c= TN RFC2543 [phone]
         m= text 1  fax -

   means that there is an implied content stored on the GSTN, and that
   this is uniquely identified by the combination of SIP To-URI and the
   Contact field of the session description.

3.4.2.4. Session Description support for included Data Objects

   As an alternative to pointing to the data via a URI or an opaque
   reference to a data item held on the GSTN, it is possible to include
   the content data within the SIP request itself. This is done by using
   multipart MIME for the SIP payload. The first MIME part contains the
   SDP description of the telephone network session to be executed. The
   other MIME parts contain the content data to be transported.




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


   Format specific attribute lines within the session description are
   used to indicate which other MIME part within the request contains
   the content data. Instead of a URI or opaque reference, the format-
   specific attribute indicates the Content-ID of the MIME part of the
   request that contains the actual data, and is defined as:

       <sub-part-ref> := ("spr:" Content-ID)

   where Content-ID is as defined in Appendix A of [3] and in [10]).

   For example:

         c= TN RFC2543 [phone]
         m= text 1  fax plain
         a=fmtp:plain  spr:<Content-ID>

   The <Content-ID> parameter is the Content-ID of one of the MIME parts
   inside the message, and this fragment means that the requesting user
   would like the data object held in the sub-part of this message
   labelled <Content-ID> to be faxed to the machine at phone number +1-
   201-406-4090.

   See also section 3.5.1 for a discussion on the support needed in the
   enclosing SIP request for included data objects.

3.4.3. Attribute Tags to pass information into the Telephone Network

   It may be desired to include within the PINT request service
   parameters that can be understood only by some entity in the
   "Telephone Network Cloud". SDP attribute parameters are used for this
   purpose. They MAY appear within a particular media description or
   outside of a media description.

   These attributes may also appear as parameters within PINT URLS (see
   section 3.5.6) as part of a SIP request.

   This is necessary so that telephone terminals that require the
   attributes to be defined can appear within the To: line of a PINT
   request as well as within PINT session descriptions.

   The purpose of these attributes is to allow the client to specify
   extra context within which a particular telephone number is to be
   interpreted.  There are many reasons why extra context might be
   necessary to interpret a given telephone number:







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


      a. The telephone number might be reachable in many different ways
         (such as via competing telephone service providers), and the
         PINT client wishes to indicate its selection of service
         provider.
      b. The telephone number might be reachable only from a limited
         number of networks (such as an '800' freephone number).
      c. The telephone number might be reachable only within a single
         telephone network (such as the '152' customer service number of
         BT). Similarly, the number might be an internal corporate
         extension reachable only within the PBX.

   However, as noted above, it is not usually necessary to use SDP
   attributes to specify the phone context. URLs such as
   [e-mail] within the To: and From: headers and/or Request-
   URI, normally offer sufficient context to resolve telephone numbers.

   If the client wishes the request to fail if the attributes are not
   supported, these attributes SHOULD be used in conjunction with the
   "require" attribute (section 3.4.4) and the
   "Require:org.ietf.sdp.require" header (section 3.5.4).

   It is not possible to standardise every possible internal telephone
   network parameter. PINT 1.0 attributes have been chosen for
   specification because they are common enough that many different PINT
   systems will want to use them, and therefore interoperability will be
   increased by having a single specification.

   Proprietary attribute "a=" lines, that by definition are not
   interoperable, may be nonetheless useful when it is necessary to
   transport some proprietary internal telephone network variables over
   the IP network, for example to identify the order in which service
   call legs are to be be made. These private attributes SHOULD BE,
   however, subject to the same IANA registration procedures mentioned
   in the SDP specification[2] (see also this Appendix C).

3.4.3.1. The phone-context attribute

   An attribute is specified to enable "remote local dialling". This is
   the service that allows a PINT client to reach a number from far
   outside the area or network that can usually reach the number. It is
   useful when the sending or receiving address is only dialable within
   some local context, which may be remote to the origin of the PINT
   client.

   For example, if Alice wanted to report a problem with her telephone,
   she might then dial a "network wide" customer care number; within the
   British Telecom network in the U.K., this is "152". Note that in this
   case she doesn't dial any trunk prefix - this is the whole dialable



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


   number. If dialled from another operator's network, it will not
   connect to British Telecom's Engineering Enquiries service; and
   dialling "+44 152" will not normally succeed. Such numbers are called
   Network-Specific Service Numbers.

   Within the telephone network, the "local context" is provided by the
   physical connection between the subscriber's terminal and the central
   office. An analogous association between the PINT client and the PINT
   server that first receives the request may not exist, which is why it
   may be necessary to supply this missing "telephone network context".
   This attribute is defined as follows:

   a=phone-context: <phone-context-ident>
   phone-context-ident     =  network-prefix / private-prefix
   network-prefix          =  intl-network-prefix / local-network-prefix
   intl-network-prefix     =  "+" 1*DIGIT
   local-network-prefix    =  1*DIGIT
   excldigandplus          =  (0x21-0x2d,0x2f,0x40-0x7d))
   private-prefix          =  1*excldigandplus 0*uric

   An intl-network-prefix and local-network-prefix MUST be a bona fide
   network prefix, and a network-prefix that is an intl-network-prefix
   MUST begin with an E.164 service code ("country code").

   It is possible to register new private-prefixes with IANA so as to
   avoid collisions. Prefixes that are not so registered MUST begin with
   an "X-" to indicate their private, non-standard nature (see Appendix
   C).

   Example 1:

         c= TN   RFC2543  1-800-765-4321
         a=phone-context:+972

   This describes an terminal whose address in Israel (E.164 country
   code 972) is 1-800-765-4321.

   Example 2:

         c= TN   RFC2543  1-800-765-4321
         a=phone-context:+1

   This describes an terminal whose address in North America (E.164
   country code 1) is 1-800-765-4321.

   The two telephone terminals described by examples 1 and 2 are
   different; in fact they are located in different countries.




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


   Example 3:

         c=TN RFC2543  123
         a=phone-context:+97252

   This describes a terminal whose address when dialled from within the