From e3264ca073c10d83b8279a18946841a62846c810 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 30 Sep 2008 14:51:31 +0000 Subject: [PATCH] corrected transport terminology git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2293 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 18 +++++++++--------- xep-0167.xml | 10 +++++----- xep-0177.xml | 8 ++++---- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/xep-0166.xml b/xep-0166.xml index bb9547c0..a0d07b4f 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -53,7 +53,7 @@ psa/ram @@ -943,7 +943,7 @@ PENDING o----------------------+ |

The transport-info action is used to exchange transport candidates; it is mainly used in XEP-0176 but might be used in other transport specifications.

-

The transport-replace action is used to redefine a transport method.

+

The transport-replace action is used to redefine a transport method, typically for fallback to a different method (e.g., changing from ICE-UDP to Raw UDP for a datagram transport, or changing from &xep0065; to &xep0047; for a streaming transport).

It is possible that two instances of certain actions can be sent at the same time in the context of an existing session, one by each party; for example, both parties might simulaneously attempt to send a content-add, content-modify, or content-remove action. In all such cases, the action sent by the initiator MUST overrule the action sent by the responder; i.e., both parties MUST accept the action sent by the initiator and the initiator MUST return an &unexpected; error to the responder for the duplicate action.

@@ -1097,8 +1097,8 @@ PENDING o----------------------+ |
  • How successful application format negotiation occurs.
  • A &DESCRIPTION; element and associated semantics for representing the application format.
  • If and how the application format can be mapped to the Session Description Protocol, including the appropriate SDP media type (see Section 8.2.1 of RFC 4566).
    • -
  • Whether the media for the application format shall be sent over a stream transport method or a datagram transport method (or, if both, which is preferred).
    • -
  • Exactly how the media is to be sent and received over a stream or datagram transport.
    • +
  • Whether the media for the application format shall be sent over a streaming transport method or a datagram transport method (or, if both, which is preferred).
    • +
  • Exactly how the media is to be sent and received over a streaming or datagram transport.
    • @@ -1106,7 +1106,7 @@ PENDING o----------------------+ |
    1. How successful transport negotiation occurs.
    2. A &TRANSPORT; element and associated semantics for representing the transport method.
      3. -
    3. Whether the transport is stream or datagram.
      4. +
    4. Whether the transport is streaming or datagram.
    5. If and how the transport handles "components" (e.g., for the Real Time Control Protocol).
     @@ -1148,7 +1148,7 @@ PENDING o----------------------+ | The name of the application format. A natural-language summary of the application format. - Whether the media can be sent over a "stream" transport, + Whether the media can be sent over a "streaming" transport, a "datagram" transport, or "both". The document in which the application format is specified. @@ -1162,7 +1162,7 @@ PENDING o----------------------+ | the name of the transport method a natural-language summary of the transport method - whether the transport method can be "stream", "datagram", or "both" + whether the transport method can be "streaming", "datagram", or "both" the document in which this transport method is specified ]]> diff --git a/xep-0167.xml b/xep-0167.xml index 41480eed..01b30d53 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -129,7 +129,7 @@ 0.9 2007-04-17 psa -

    Specified Jingle conformance, including the preference for lossy transports over reliable transports and the process of sending and receiving audio content over each transport type.

     +

    Specified Jingle conformance, including the preference for datagram transports over streaming transports and the process of sending and receiving audio content over each transport type.

     0.8 @@ -218,12 +218,12 @@

  • The application format negotiation process is defined in the Negotiating a Jingle RTP Session section of this document.

  • The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.

  • A mapping of Jingle semantics to the Session Description Protocol is provided in the Mapping to Session Description Protocol section of this document.

    • -

  • A Jingle RTP session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;, but MAY use a reliable transport such as "ice-tcp" if a low-bandwidth codec is employed and the media negotiated is not unduly heavy (e.g., it might be possible to use a reliable transport for audio, but not for video).

    • +

  • A Jingle RTP session SHOULD use a datagram transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;, but MAY use a streaming transport such as "ice-tcp" if a low-bandwidth codec is employed and the media negotiated is not unduly heavy (e.g., it might be possible to use a streaming transport for audio, but not for video).

  • Content is to be sent and received as follows:

      -

    • For lossy transports, outbound content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.

      • -

    • For reliable transports, outbound content shall be encoded into RTP packets and each packet data shall be sent in succession over the transport. Incoming data received over the transport shall be processed as a stream of RTP packets, where each RTP packet boundary marks the location of the next packet.

      • +

    • For datagram transports, outbound content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.

      • +

    • For streaming transports, outbound content shall be encoded into RTP packets and each packet data shall be sent in succession over the transport. Incoming data received over the transport shall be processed as a stream of RTP packets, where each RTP packet boundary marks the location of the next packet.

    • @@ -1644,7 +1644,7 @@ Romeo Juliet Jingle sessions that support media exchange via the Real-time Transport Protocol. - lossy + datagram XEP-0167 ]]> diff --git a/xep-0177.xml b/xep-0177.xml index 2d4c139d..13506e4f 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -61,7 +61,7 @@ 0.6 2007-04-17 psa -

    Specified Jingle conformance, including definition of transport type as lossy; added section on service discovery.

     +

    Specified Jingle conformance, including definition of transport type as datagram; added section on service discovery.

         0.5 @@ -95,7 +95,7 @@ -

    &xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) "connection" (see &rfc0768;). This "raw-udp" method results in a lossy transport method suitable for use in media applications where some packet loss is tolerable (e.g., audio and video).

    +

    &xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) "connection" (see &rfc0768;). This "raw-udp" method results in a datagram transport method suitable for use in media applications where some packet loss is tolerable (e.g., audio and video).

    Note: The Raw UDP transport does not provide end-to-end traversal of Network Address Translators (NATs); if NAT traversal is needed, Jingle clients SHOULD use &ice; as described in &xep0176;. The Raw UDP transport method is defined only for the purpose of specifying the IP address and port that an entity considers "most likely to succeed" and is a "hit-or-miss" method that might work end-to-end in some circumstances. However, this method can prove useful when the communications architecture includes intermediate gateways or relays, as described in XEP-0176.

     @@ -111,7 +111,7 @@

    1. The transport negotiation process is defined in the Protocol Description section of this document.

    2. The semantics of the &TRANSPORT; element are defined in the Transport Initiation section of this document.

      3. -

    3. Successful negotiation of the Raw UDP method results in use of a lossy transport that is suitable for applications where some packet loss is tolerable, such as audio and video.

      4. +

    4. Successful negotiation of the Raw UDP method results in use of a datagram transport that is suitable for applications where some packet loss is tolerable, such as audio and video.

    5. If multiple components are to be communicated over the transport, the first component shall be associated with the port in the transport initiation stanza and the second component (e.g., for RTCP) shall be associated with a UDP port that is one number higher than the specified port (e.g., if the specified port is 13540 then the port for the second component shall be 13541).

     @@ -328,7 +328,7 @@ raw-udp A method for exchanging data over raw UDP datagrams. - lossy + datagram XEP-0177 ]]>