rfc2848.txt

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

3.3. REQUIRED and OPTIONAL elements for PINT compliance

   Of these, only the TN network type (with its associated RFC2543
   address type) and the "require" attribute MUST be supported by PINT
   1.0 clients and servers. In practice, most PINT service requests will
   use other changes, of which references to Data Objects in requests
   are most likely to appear in PINT requests.

   Each of the other new PINT constructs enables a different function,
   and a client or server that wishes to enable that particular function
   MUST do so by the construct specified in this document. For example,
   building a PINT client and server that provide only the Request-to-
   Call telephone call service, without support for the other Milestone
   services, is allowed.

   The "Require:" SIP header and the "require" attribute provide a
   mechanism that can be used by clients and servers to signal their
   need and/or ability to support specific "new" PINT protocol elements.





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


   It should be noted that many optional features of SIP and SDP make
   sense as specified in the PINT context. One example is the SDP
   a=lang:  attribute, which can be used to describe the preferred
   language of the callee. Another example is the use of the "t="
   parameter to indicate that the time at which the PINT service is to
   be invoked. This is the normal use of the "t=" field. A third example
   is the quality attributes.  Any SIP or SDP option or facility is
   available to PINT clients and servers without change.

   Conversely, support for Data Objects within Internet Conference
   sessions may be useful, even if the aim is not to provide a GSTN
   service request.  In this case, the extensions covering these items
   may be incorporated into an otherwise "plain" SIP/SDP invitation.
   Likewise, support for SDP "require" may be useful, as a framework for
   addition of features to a "traditional" SIP/SDP infrastructure.
   Again, these may be convenient to incorporate into SIP/SDP
   implementations that would not be used for PINT service requests.
   Such additions are beyond the scope of this document, however.

3.4. PINT Extensions to SDP

   PINT 1.0 adds to SDP the possibility to describe audio, fax, and
   pager telephone sessions. It is deliberately designed to hide the
   underlying technical details and complexity of the telephone network.
   The only network type defined for PINT is the generic "TN" (Telephone
   Network).  More precise tags such as "ISDN", "GSM", are not defined.
   Similarly, the transport protocols are designated simply as "fax",
   "voice", and "pager"; there are no more specific identifiers for the
   various telephone network voice, fax, or pager protocols. Similarly,
   the data to be transported are identified only by a MIME content
   type, such as "text" data, "image" data, or some more general
   "application" data. An important example of transporting
   "application" data is the milestone service "Voice Access to Web
   Content". In this case the data to be transported are pointed to by a
   URI, the data content type is application/URI, and the transport
   protocol would be "voice". Some sort of speech-synthesis facility,
   speaking out to a Phone, will have to be invoked to perform this
   service.

   This section gives details of the new SDP keywords.

3.4.1. Network Type "TN" and Address Type "RFC2543"

   The TN ("Telephone Network") network type is used to indicate that
   the terminal is connected to a telephone network.

   The address types allowed for network type TN are "RFC2543" and
   private address types, which MUST begin with an "X-".



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


   Address type RFC2543 is followed by a string conforming to a subset
   of the "telephone-subscriber" BNF specified in figure 4  of SIP [1]).
   Note that this BNF is NOT identical to the BNF that defines the
   "phone-number" within the "p=" field of SDP.

   Examples:

       c= TN  RFC2543  [phone]

       c= TN  RFC2543  12014064090

   A telephone-subscriber string is of one of two types:  global-phone-
   number or local-phone-number.  These are distinguished by preceeding
   a global-phone-number with a "plus" sign ("+"). A global-phone-number
   is by default to be interpreted as an internationally significant
   E.164 Number Plan Address, as defined by [6], whilst a local-phone-
   number is a number specified in the default dialling plan within the
   context of the recipient PINT Gateway.

   An implementation MAY use private addressing types, which can be
   useful within a local domain. These address types MUST begin with an
   "X-", and SHOULD contain a domain name after the X-, e.g. "X-
   mytype.mydomain.com".  An example of such a connection line is as
   follows:

         c= TN X-mytype.mydomain.com  A*8-HELEN

   where "X-mytype.mydomain.com" identifies this private address type,
   and "A*8-HELEN" is the number in this format. Such a format is
   defined as an "OtherAddr" in the ABNF of Appendix A. Note that most
   dialable telephone numbers are expressable as local-phone-numbers
   within address RFC2543; new address types SHOULD only be used for
   formats which cannot be so written.

3.4.2. Support for Data Objects within PINT

   One significant change over traditional SIP/SDP Internet Conference
   sessions with PINT is that a PINT service request may refer to a Data
   Object to be used as source information in that request. For example,
   a PINT service request may specify a document to be processed as part
   of a GSTN service by which a Fax is sent. Similarly, a GSTN service
   may be take a Web page and result in a vocoder processing that page
   and speaking the contents over a telephone.

   The SDP specification does not have explicit support for reference to
   or carriage of Data Objects within requests. In order to use SDP for
   PINT, there is a need to describe such media sessions as "a telephone




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


   call to a certain number during which such-and-such an image is sent
   as a fax".

   To support this, two extensions to the session description format are
   specified. These are some new allowed values for the Media Field, and
   a description of the "fmtp" parameter when used with the Media Field
   values (within the context of the Contact Field Network type "TN").

   An addition is also made to the SIP message format to allow the
   inclusion of data objects as sub-parts within the request message
   itself. The original SDP syntax (from [2]) for media-field is given
   as:

      media-field =         "m=" media space port ["/" integer]
                            space proto 1*(space fmt) CRLF

   When used within PINT requests, the definition of the sub-fields is
   expanded slightly. The Media sub-field definition is relaxed to
   accept all of the discrete "top-level" media types defined in [4]. In
   the milestone services the discrete type "video" is not used, and the
   extra types "data" and "control" are likewise not needed. The use of
   these types is not precluded, but the behaviour expected of a PINT
   Gateway receiving a request including such a type is not defined
   here.

   The Port sub-field has no meaning in PINT requests as the destination
   terminals are specified using "TN" addressing, so the value of the
   port sub-field in PINT requests is normally set to "1". A value of
   "0" may be used as in SDP to indicate that the terminal is not
   receiving media.  This is useful to indicate that a telephone
   terminal has gone "on hold" temporarily.  Likewise, the optional
   integer sub-field is not used in PINT.

   As mentioned in [2], the Transport Protocol sub-field is specific to
   the associated Address Type. In the case that the Address Type in the
   preceeding Contact field is one of those defined for use with the
   Network Type "TN", the following values are defined for the Transport
   Protocol sub-field:

   "voice", "fax", and "pager".

   The interpretation of this sub-field within PINT requests is the
   treatment or disposition of the resulting GSTN service. Thus, for
   transport protocol "voice", the intent is that the service will
   result in a GSTN voice call, whilst for protocol "fax" the result
   will be a GSTN fax transmission, and protocol "pager" will result in
   a pager message being sent.




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


   Note that this sub-field does not necessarily dictate the media type
   and subtype of any source data; for example, one of the milestone
   services calls for a textual source to be vocoded and spoken in a
   resulting telephone service call. The transport protocol value in
   this case would be "voice", whilst the media type would be "text".

   The Fmt sub-field is described in [2] as being transport protocol-
   specific. When used within PINT requests having one of the above
   protocol values, this sub-field consists of a list of one or more
   values, each of which is a defined MIME sub-type of the associated
   Media sub-field value. The special value "-" is allowed, meaning that
   there is no MIME sub-type. This sub-field retains (from [2]) its
   meaning that the list will contain a set of alternative sub-types,
   with the first being the preferred value.

   For experimental purposes and by mutual consent of the sender and
   recipient, a sub-type value may be specified as an <X-token>, i.e. a
   character string starting with "X-". The use of such values is
   discouraged, and if such a value is expected to find common use then
   it SHOULD be registered with IANA using the standard content type
   registration process (see Appendix C).

   When the Fmt parameter is the single character "-" ( a dash ), this
   is interpreted as meaning that a unspecified or default sub-type can
   be used for this service. Thus, the media field value "m=audio 1
   voice -<CRLF>" is taken to mean that a voice call is requested, using
   whatever audio sub type is deemed appropriate by the Executive
   System. PINT service is a special case, in that the request comes
   from the IP network but the service call is provided within the GSTN.
   Thus the service request will not normally be able to define the
   particular codec used for the resulting GSTN service call. If such an
   intent IS required, then the quality attribute may be used (see
   "Suggested Attributes" section of [2]).

3.4.2.1. Use of fmtp attributes in PINT requests

   For each element of the Fmt sub-field, there MUST be a following fmtp
   attribute. When used within PINT requests, the fmtp attribute has a
   general structure as defined here:

       "a=fmtp:" <subtype> <space> resolution
                          *(<space> resolution)
                          (<space> ";" 1(<attribute>)
                                       *(<space> <attribute>))
   where:
       <resolution> := (<uri-ref> | <opaque-ref> | <sub-part-ref>)





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


   A fmtp attribute describes the sources used with a given Fmt entry in
   the Media field. The entries in a Fmt sub-field are alternatives
   (with the preferred one first in the list). Each entry will have a
   matching fmtp attribute. The list of resolutions in a fmtp attribute
   describes the set of sources that resolve the matching Fmt choice;
   all elements of this set will be used.

   It should be noted that, for use in PINT services, the elements in
   such a set will be sent as a sequence; it is unlikely that trying to
   send them in parallel would be successful.

   A fmtp attribute can contain a mixture of different kinds of element.
   Thus an attribute might contain a sub-part-ref indicating included
   data held in a sub-part of the current message, followed by an
   opaque-ref referring to some content on the GSTN, followed by a uri-
   ref pointing to some data held externally on the IP network.

   To indicate which form each resolution element takes, each of them
   starts with its own literal tag. The detailed syntax of each form is
   described in the following sub-sections.

3.4.2.2. Support for Remote Data Object References in PINT

   Where data objects stored elsewhere on the IP Network are to be used
   as sources for processing within a PINT service, they may be referred
   to using the uri-ref form. This is simply a Uniform Resource
   Identifier (URI), as described in [9].

   Note that the reference SHOULD be an absolute URI, as there may not
   be enough contextual information for the recipient server to resolve
   a relative reference; any use of relative references requires some
   private agreement between the sender and recipient of the message,
   and SHOULD be avoided unless the sender can be sure that the
   recipient is the one intended and the reference is unambiguous in
   context.

   This also holds for partial URIs (such
   as"uri:http://aNode/index.htm") as these will need to be resolved in
   the context of the eventual recipient of the message.

   The general syntax of a reference to an Internet-based external data
   object in a fmtp line within a PINT session description is:

       <uri-ref> := ("uri:" URI-reference)