From 30c0e335dc91973cfb0c49deaff5d4f73dbe9ad7 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 6 Apr 2009 23:21:51 +0000 Subject: [PATCH] typos git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3001 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 92 ++++++++++++++++++++++++++-------------------------- 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/xep-0166.xml b/xep-0166.xml index 854c137b..a44ccfda 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -354,7 +354,7 @@

This section provides a friendly introduction to Jingle.

-

In essence, Jingle enables two XMPP entities (e.g., romeo@montague.lit and juliet@capulet.lit) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer typically takes place outside of XMPP. A simplified session flow would be as follows: Naturally, more complex scenarios are possible; such scenarios are described in other specifications, such as XEP-0167 for voice and video chat.

+

In essence, Jingle enables two XMPP entities (e.g., romeo@montague.lit and juliet@capulet.lit) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer typically takes place outside of XMPP. A simplified session flow would be as follows: Naturally, more complex scenarios are possible; such scenarios are described in other specifications, such as Jingle RTP Sessions for voice and video chat.

]]>

In this example, the initiator (romeo@montague.lit/orchard) sends a session initiation offer to the responder (juliet@capulet.lit/balcony), where the session is defined as the exchange of "stub" media over a "stub" transport.

-

After the responding client acknowledges receipt of the session-initiate message, it prompts the responding user (if any) to choose whether she wants to proceed with the session (however, it does not need to prompt the user if for example she has configured her client to automatically accept session requests from this particular initiator). If she wants to proceed she selects the appropriate interface element and her client sends a session-accept message to the initiator.

+

After the responding client acknowledges receipt of the session-initiate message (not shown here), it prompts the responding user (if any) to choose whether she wants to proceed with the session (however, it does not need to prompt the user if for example she has configured her client to automatically accept session requests from this particular initiator). If she wants to proceed she selects the appropriate interface element and her client sends a session-accept message to the initiator.

]]> -

The initiator's acknowledges receipt of the session-terminate message (not shown here) and the session is ended.

-

We now "fill in the blanks" for the &DESCRIPTION; and &TRANSPORT; elements with a more complex example: a voice chat session, where application type is a Jingle RTP session (with several different codec possibilities) and the transport method is &xep0176;.

+

The initiating client acknowledges receipt of the session-terminate message (not shown here) and the session is ended.

+

We now "fill in the blanks" for the &DESCRIPTION; and &TRANSPORT; elements with a more complex example: a voice chat session, where the application type is a Jingle RTP session (with several different codec possibilities) and the transport method is ICE-UDP.

Transport Method - The method for establishing data stream(s) between entities. Possible transports might include ICE-UDP, ICE-TCP, Raw UDP, In-Band Bytestreams, SOCKS5 Bytestreams, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method MUST specify whether it is "datagram" or "streaming" as described in the Transport Types sectio of this document. + The method for establishing data stream(s) between entities. Possible transports might include ICE-UDP, ICE-TCP, Raw UDP, In-Band Bytestreams, SOCKS5 Bytestreams, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method MUST specify whether it is "datagram" or "streaming" as described in the Transport Types section of this document. @@ -622,7 +622,7 @@ Romeo Juliet
  • Optionally, the parties attempt to establish security for the transport method before using it to exchange application data.
  • Optionally, either party can add or remove content definitions, or change the direction of the media flow, using the content-add, content-remove, and content-modify messages.
  • Optionally, either party can send session-info messages (e.g., to inform the other party that its device is ringing).
    • -
  • As soon as the responder determines that data can flow over the negotiated transport (potentially only after a security precondition has been met), they start sending application data over the transport.
    • +
  • As soon as the initiator and responder determine that data can flow over the negotiated transport (potentially only after a security precondition has been met), they start sending application data over the transport.

    • Even after application data is being exchanged, the parties can adjust the session definition by sending additional Jingle messages, such as content-modify, content-remove, content-add, description-info, security-info, session-info, and transport-replace.

    @@ -632,43 +632,43 @@ Romeo Juliet | | session-initiate | - | +------------------------+ - |/ | -PENDING o----------------------+ | - | | content-accept, | | - | | content-add, | | - | | content-modify, | | - | | content-reject, | | - | | content-remove, | | - | | description-info, | | - | | session-info, | | - | | transport-accept, | | - | | transport-info, | | - | | transport-reject, | | - | | transport-replace | | - | +-------------------+ | - | | - | session-accept | - | | - ACTIVE o----------------------+ | - | | content-accept, | | - | | content-add, | | - | | content-modify, | | - | | content-reject, | | - | | content-remove, | | - | | description-info, | | - | | session-info, | | - | | transport-accept, | | - | | transport-info, | | - | | transport-reject, | | - | | transport-replace | | - | +-------------------+ | - | | - +--------------------------+ - | - | session-terminate - | - o ENDED + | +---------->--------------+ + |/ | +PENDING o-----------------------+ | + | | content-accept, | | + | | content-add, | | + | | content-modify, | | + | | content-reject, | | + | | content-remove, | | + | | description-info, | | + \|/ | session-info, | | + | | transport-accept, | | + | | transport-info, | | + | | transport-reject, | | + | | transport-replace | | + | +-------------------+ | + | | + | session-accept \|/ + | | + ACTIVE o-----------------------+ | + | | content-accept, | | + | | content-add, | | + | | content-modify, | | + | | content-reject, | | + | | content-remove, | | + | | description-info, | | + \|/ | session-info, | | + | | transport-accept, | | + | | transport-info, | | + | | transport-reject, | | + | | transport-replace | | + | +-------------------+ | + | | + +------------>--------------+ + | + | session-terminate + | + o ENDED

    As shown, there are three overall session states:

      @@ -676,7 +676,7 @@ PENDING o----------------------+ |
    1. ACTIVE
    2. ENDED
    -

    Note: While it is allowed to send all actions while in the PENDING state, typically the responder will send a session-accept message as quickly as possible in order to expedite the transport negotiation; see the Security Considerations section of this document regarding informatino exposure when the responder sends transport candidates to the initiator.

    +

    Note: While it is allowed to send all actions while in the PENDING state, typically the responder will send a session-accept message as quickly as possible in order to expedite the transport negotiation; see the Security Considerations section of this document regarding information exposure when the responder sends transport candidates to the initiator.

    The actions related to management of the overall Jingle session are as follows (detailed definitions are provided in the Action Attribute section of this document).