Table of Contents
This document describes the XMPP signaling and other related protocols used at the time of writing by Google Talk (and the libjingle library on which it is based) to conduct voice and video calls. It is intended for use by third-party IM client developers who would like to achieve interoperability with Google Talk/Gmail voice and video chat. For more Google Talk developer information, please refer to the Google Talk Developer Documentation page.
The relevant XMPP extension standard, XEP-0167: Jingle RTP Sessions, has recently been advanced to Draft status by the XMPP Standards Foundation. Future versions of Google Talk with comply with this standard; in the meantime, the protocol described in this document is our current working version.
This document describes the current signaling protocol as used by Google Talk and Gmail video chat.
Note that when using this document, you may encounter undocumented issues for your client -- if this happens, or if anything in the document is unclear, please let us know. You can send feedback on this document to xmpp+jingle@google.com.
This section describes the general process for negotiating a Google Talk call. During the negotiation, XMPP Info/Query ("IQ") messages of type "set" are exchanged between the call parties. These IQ messages are sent as specified in RFC 3920; each message is acknowledged with an IQ result (if the message is processed successfully) or error (if an error occurs when processing the message). Details of the specific types of IQ messages used during the process can be found in the Messages section below.
The following diagram shows the basic process for a successful call:
|
INITIATOR RESPONDER
| |
| initiate (1) |
|----------------------------------->|
| ack (1) |
|<-----------------------------------|
| candidates (2) |
|----------------------------------->|
| ack (2) |
|<-----------------------------------|
| candidates (2) |
|<-----------------------------------|
| ack (2) |
|----------------------------------->|
| STUN Binding Request (3) |
|===================================>|
| STUN Binding Result (3) |
|<===================================|
| STUN Binding Request (3) |
|<===================================|
| STUN Binding Result (3) |
|===================================>|
| accept (4) |
|<-----------------------------------|
| ack (4) |
|----------------------------------->|
|<=======AUDIO/VIDEO RTP (5)========>|
|----------------------------------->|
| terminate (6) |
|----------------------------------->|
| ack (6) |
|<-----------------------------------|
| |
Messages are described by example, with additional notes in comments.
Each <iq> message contains a <session> element with xmlns="http://www.google.com/session". This <session> element contains the following attributes:
<iq> element.An initiate message initiates a Google Talk call, specifying the initiator and all the payload types the initiator can send/receive. For an initiate message, the <session> element contains the following elements:
<description> element, multiple <payload-type> elements are specified to indicate the media formats that the initiator can receive. For a video call, both audio and video payload types are contained within the description element; XML namespaces are used to distinguish between the two. Within the <payload-type> element, the following attributes are specified, depending on whether the payload is for audio or video:The Google Talk (version 1.0.0.x) client will also include a <transport> element within the <session> element of its initiate stanza, to explicitly indicate what transport it wants to use. Clients following this specification should assume the use of the ICE transport, ignore any <transport> element, and not include one in their own initiate stanza. Presence of the <transport> element will cause the Google Talk client to use a slightly different format when negotiating transport candidates, which has since been deprecated.
<iq from="tobe@localhost/11234"
to="tobetest@gmail.com/gmail.B4FC4A6D"
id="BE54746B"
type="set">
<session type="initiate"
initiator="tobe@localhost/11234"
id="11234"
xmlns="http://www.google.com/session">
<description xmlns="http://www.google.com/session/video">
<payload-type xmlns="http://www.google.com/session/phone"
id="103"
name="ISAC"
clockrate="16000"/>
<!-- alternative audio payload-types may be specified -->
<payload-type xmlns="http://www.google.com/session/video"
id="96"
name="H264-SVC"
width="320"
height="200"
framerate="30"/>
<!-- alternative video payload-types may be specified -->
</description>
</session>
</iq>
A candidates message describes a candidate transport for the channel. As described in the Sequence Of Events section above, once an initiate is acknowledged, both call parties send candidates and probe those they receive (using ICE) until a candidate pair is successful and the responder accepts. This process is described further in the ICE Transport section below. For a candidates message, the <session> element contains the following elements:
<candidate> element, the following attributes are specified:
<iq from="tobe@localhost/11234"
to="tobetest@gmail.com/gmail.B4FC4A6D"
id="BE54746C"
type="set">
<session type="candidates"
id="11234"
initiator="tobe@localhost/11234"
xmlns="http://www.google.com/session">
<candidate name="rtp"
address="127.0.0.1"
port="60802"
preference="1" <!-- ranges from 0.0-1.0 -->
type="stun" <!-- can be local, stun, or relay -->
protocol="udp" <!-- can be udp, tcp or ssltcp -->
network="0" <!-- 0-based index of network adapters -->
username="EiuU8u5pNNMXsVJ/" <!-- for ice -->
password="GoVuJl7O2vQTyNln" <!-- for ice -->
generation="0"/>
<!-- more candidate elements may appear in the same session element
and/or several messages with candidates may be sent -->
</session>
</iq>
An accept message is sent by the call responder once the call can go ahead, specifying the payload types chosen/accepted. For an accept message, the <session> element contains the following elements:
<unsupported-applications/> reason code.
<iq to="tobe@localhost/11234"
type="set"
id="7CE1B8A66E9C01DB"
from="tobetest@gmail.com/gmail.B4FC4A6D">
<session type="accept"
initiator="tobe@localhost/11234"
id="11234"
xmlns="http://www.google.com/session">
<description xmlns="http://www.google.com/session/video">
<payload-type xmlns="http://www.google.com/session/phone"
id="103"
name="ISAC"
clockrate="16000"/>
<!-- alternative audio payload-types may be specified -->
<payload-type xmlns="http://www.google.com/session/video"
id="96"
name="H264-SVC"
width="320"
height="200"
framerate="30"/>
<!-- alternative video payload-types may be specified -->
</description>
</session>
</iq>
A reject message is used instead of an accept when the call is explicitly declined by the recipient. The <session> element does not contain any child elements.
<iq to="tobe@localhost/11234"
type="set"
id="2E6296FD07416697"
from="tobetest@gmail.com/gmail.B4FC4A6D">
<session type="reject"
initiator="tobe@localhost/11234"
id="11234"
xmlns="http://www.google.com/session"/>
</iq>
A terminate message is used to terminate a call. A reason code may be optionally specified as a child of the <session> element.
<iq to="tobe@localhost/11234"
type="set"
id="E502DCEBAFC5C521"
from="tobetest@gmail.com/gmail.B4FC4A6D">
<session type="terminate"
initiator="tobe@localhost/11234"
id="11234"
xmlns="http://www.google.com/session">
<busy/>
</session>
</iq>
The list of supported reason codes will be added to a future version of this document.
As mentioned above, audio and video media is transmitted over RTP streams using the ICE transport. For audio calls, only a single "rtp" channel is used; RTCP is not currently used for these calls. Video calls establish RTP and RTCP channels for both audio and video media, resulting in four channels named "rtp", "rtcp", "video_rtp" and "video_rtcp".
The establishment of and maintenance of RTP and RTCP channels is done by performing connectivity checks against all received candidates using STUN binding requests and responses. For a given candidate to be considered usable, it must respond to a STUN binding request with an appropriate STUN binding response. In addition to the initial connectivity checks, STUN is used after the channel is established to ensure it is still alive.
During the call, if multiple usable candidates are available, the client may switch from the one it is currently using to another one, if that one seems to be working better.
Note that the client verifies that received packets are coming from a valid candidate port on the remote machine.
The Google Talk client and Gmail voice and video chat support many common voice codecs, including G.711, Speex, iLBC, and ISAC. The voice codecs offered by the Gmail client, as they would appear in the session description, are listed below:
<payload-type id="103" name="ISAC" clockrate="16000"/> <payload-type id="97" name="IPCMWB" bitrate="80000" clockrate="16000"/> <payload-type id="99" name="speex" bitrate="22000" clockrate="16000"/> <payload-type id="102" name="iLBC" bitrate="13300" clockrate="8000"/> <payload-type id="98" name="speex" bitrate="11000" clockrate="8000"/> <payload-type id="100" name="EG711U" bitrate="64000" clockrate="8000"/> <payload-type id="101" name="EG711A" bitrate="64000" clockrate="8000"/> <payload-type id="0" name="PCMU" bitrate="64000" clockrate="8000"/> <payload-type id="8" name="PCMA" bitrate="64000" clockrate="8000"/> <payload-type id="106" name="telephone-event" clockrate="8000"/>
The payload IDs listed here are shown for example purposes only; different Google clients may use different values for the dynamic payload types (those above 95). Note also that separate payload types are used for the same codec with different clockrates. This is so that the decoder will be able to unambiguously decode a payload with a given id.
Where standards exist (iLBC, Speex, and PCMU/PCMA), RTP packetization is as specified in the respective RFCs.
Most of the supported audio codecs specify a fixed bitrate, which is indicated during session negotiation. ISAC is dynamic bitrate from 18-48 Kbps; this bitrate is negotiated in-band by a proprietary mechanism.
By default Google Talk does not request the use of VAD. However, it will support it if the other side advertises it in its initiate/accept message. This is done by specifying a payload-type with name="CN", similar to how this is indicated in RFC 3389.
Currently, only Gmail voice and video chat supports sending and receiving video. At this time, the H.264/SVC and H.264/AVC codecs are supported. Other codecs may be supported in future versions. The video codecs supported by the Gmail client are listed below:
<payload-type id="96" name="H264-SVC" width="320" height="200" framerate="30"/> <payload-type id="97" name="H264" width="320" height="200" framerate="30"/>
Note that the width, height, and framerate parameters are 'hints' to the sender that specify what the receiver prefers to decode; these values should be chosen based on the capabilities of the receiving client. When interpreting these values, the sender may send the specified resolution, a lower resolution, or a similar resolution with a different aspect ratio. For example, to a client that prefers 320x200, the sender may choose to send 320x200, 160x100, or 320x240, depending on what is best for the sender. The sender should not send a resolution/framerate that markedly exceeds that specified by the sender. For example, to a client that prefers 320x200, the sender should not choose to send 640x400, as the receiver may not be capable of decoding it.
The RTP packetization for H.264/SVC has not been finalized; we intend to comply with the standard when it is finalized. RTP packetization for H.264/AVC is as specified in RFC 3984.
H.264 is capable of scaling its bitrate dynamically. We use a mechanism based on TCP Friendly Rate Control (TFRC) to determine the available bandwidth and adjust the rate accordingly. There are two components to this mechanism, a TFRC value written into a RTP extension header in each outgoing RTP packet, and a RTCP feedback message indicating the available bandwidth, which will be used by the receiving client to adjust its send bitrate.
The format for the RTP extension header is based on this draft: http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10.
The format for the RTCP feedback message will be added to a future version of this document.
The Google Talk client uses capabilities to determine whether users support the Google Talk voice and video functionality. There are three capabilities currently defined, which are specified in the ext attribute of a XEP-0115 capabilities element:
<c xmlns="http://jabber.org/protocol/caps" node="http://mail.google.com/xmpp/client/caps" ver="1.0" ext="voice-v1 video-v1 camera-v1"/>
When there are multiple possible endpoints (i.e. XMPP resources) to receive a call, the initiating Google client will select what it considers to be the "best" endpoint to receive the call. Currently, forking of calls is not supported, although it is expected to be implemented in a future version.
For voice calls, the following algorithm is used:
For video calls, the following algorithm is used:
Note that Gmail will combine all of its endpoints (i.e. multiple Gmail logins) into a single XMPP resource, which will aggregate the capabilities of the individual endpoints. When receiving a call, the Gmail server will use its own knowledge about endpoint capabilities and activity to determine the best endpoint to send the call on to.
The following examples show all the IQ messages sent over the course of various audio and video calls. Messages with a red border are from the call initiator, while those with a blue border are from the responder. As you can see, each message is acknowledged with a result, specifying the id of the corresponding received message.
Note the use of multiple candidates for the "rtp" channel by each party.
<iq from="romeo@montague.lit/orchard"
id="s1"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="initiate"
id="c1451315399"
initiator="romeo@montague.lit/orchard">
<description xmlns="http://www.google.com/session/phone">
<payload-type id="103" name="ISAC" clockrate="16000"/>
<payload-type id="97" name="IPCMWB" bitrate="80000" clockrate="16000"/>
<payload-type id="99" name="speex" bitrate="22000" clockrate="16000"/>
<payload-type id="102" name="iLBC" bitrate="13300" clockrate="8000"/>
<payload-type id="98" name="speex" bitrate="11000" clockrate="8000"/>
<payload-type id="100" name="EG711U" bitrate="64000" clockrate="8000"/>
<payload-type id="101" name="EG711A" bitrate="64000" clockrate="8000"/>
<payload-type id="0" name="PCMU" bitrate="64000" clockrate="8000"/>
<payload-type id="8" name="PCMA" bitrate="64000" clockrate="8000"/>
<payload-type id="106" name="telephone-event" clockrate="8000"/>
</description>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="s1"
to="romeo@montague.lit/orchard"
type="result"/>
<iq from="romeo@montague.lit/orchard"
id="s2"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1451315399"
initiator="romeo@montague.lit/orchard">
<candidate name="rtp"
address="192.168.0.2"
port="52979"
username="on5H+jOtbbtyl0+v"
password="gyByxv1RnT4+7Avc"
preference="1"
protocol="udp"
generation="0"
network="0"
type="local"/>
</session>
</iq>
<iq from="romeo@montague.lit/orchard"
id="s3"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1451315399"
initiator="romeo@montague.lit/orchard">
<candidate name="rtp"
address="1.2.3.4"
port="37107"
username="XNoSW2+dLS9qEFHk"
password="Q22L+DDGo0n6wuAb"
preference="0.9"
protocol="udp"
generation="0"
network="0"
type="stun"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="r1"
to="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1451315399"
initiator="romeo@montague.lit/orchard">
<candidate name="rtp"
address="10.0.0.2"
port="4252"
preference="1"
username="5YLxyCK76448axGr"
protocol="udp"
generation="0"
password="8+La8XwWBatOOR04"
type="local"
network="0"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="r2"
to="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1451315399"
initiator="romeo@montague.lit/orchard">
<candidate name="rtp"
address="5.6.7.8"
port="4253"
preference="0.9"
username="U0rxLvgkAk5sx0p9"
protocol="udp"
generation="0"
password="X6qADZn9s44+IKUx"
type="stun"
network="0"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="s2"
to="romeo@montague.lit/orchard"
type="result"/>
<iq from="juliet@capulet.lit/balcony"
id="s3"
to="romeo@montague.lit/orchard"
type="result"/>
<iq to="romeo@montague.lit/orchard"
id="r1"
from="juliet@capulet.lit/balcony"
type="result"/>
<iq to="romeo@montague.lit/orchard"
id="r1"
from="juliet@capulet.lit/balcony"
type="result"/>
<iq from="romeo@montague.lit/orchard"
id="r3"
to="juliet@capulet.lit/balcony"
type="set"/>
<session xmlns="http://www.google.com/session"
type="accept"
id="c1451315399"
initiator="romeo@montague.lit/orchard">
<description xmlns="http://www.google.com/session/phone">
<payload-type id="103" name="ISAC" clockrate="16000"/>
<payload-type id="97" name="IPCMWB" clockrate="16000" bitrate="80000"/>
<payload-type id="99" name="speex" clockrate="16000" bitrate="22000"/>
<payload-type id="102" name="iLBC" clockrate="8000" bitrate="13300"/>
<payload-type id="98" name="speex" clockrate="8000" bitrate="11000"/>
<payload-type id="100" name="EG711U" clockrate="8000" bitrate="64000"/>
<payload-type id="101" name="EG711A" clockrate="8000" bitrate="64000"/>
<payload-type id="0" name="PCMU" clockrate="8000" bitrate="64000"/>
<payload-type id="8" name="PCMA" clockrate="8000" bitrate="64000"/>
<payload-type id="106" name="telephone-event" clockrate="8000"/>
</description>
</session>
</iq>
<iq to="juliet@capulet.lit/balcony"
id="r3"
from="romeo@montague.lit/orchard"
type="result"/>
<iq to="juliet@capulet.lit/balcony"
id="s4"
from="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="terminate"
id="c1451315399"
initiator="romeo@montague.lit/orchard">
<success/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="s4"
to="romeo@montague.lit/orchard"
type="result"/>
<iq from="romeo@montague.lit/orchard"
id="s1"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="initiate"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<description xmlns="http://www.google.com/session/video">
<payload-type id="96" name="H264-SVC" width="320" height="200" framerate="30"/>
<payload-type id="103" name="ISAC" clockrate="16000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="97" name="IPCMWB" bitrate="80000" clockrate="16000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="99" name="speex" bitrate="22000" clockrate="16000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="102" name="iLBC" bitrate="13300" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="98" name="speex" bitrate="11000" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="100" name="EG711U" bitrate="64000" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="101" name="EG711A" bitrate="64000" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="0" name="PCMU" bitrate="64000" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="8" name="PCMA" bitrate="64000" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="106" name="telephone-event" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
</description>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="s1"
to="romeo@montague.lit/orchard"
type="result"/>
<iq from="romeo@montague.lit/orchard"
id="s2"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="rtp"
address="192.168.0.2"
port="52979"
username="KcVNlN3GilL593k/"
password="7N5A2keU13yo/Abk"
preference="1"
protocol="udp"
generation="0"
network="0"
type="local"/>
</session>
</iq>
<iq from="romeo@montague.lit/orchard"
id="s3"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="rtcp"
address="192.168.0.2"
port="52980"
username="pxFyhd6lUm+6rZ5N"
password="nHIVwJyMqAeQIhDK"
preference="1"
protocol="udp"
generation="0"
network="0"
type="local"/>
</session>
</iq>
<iq from="romeo@montague.lit/orchard"
id="s4"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="video_rtp"
address="192.168.0.2"
port="52981"
username="ITdrwHBGOhVg6pWW"
password="y4FwqAgIjMSv/JnM"
preference="1"
protocol="udp"
generation="0"
network="0"
type="local"/>
</session>
</iq>
<iq from="romeo@montague.lit/orchard"
id="s5"
to="juliet@capulet.lit/balcony"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="video_rtcp"
address="192.168.0.2"
port="52982"
username="5Q4txm1vACIArjC/"
password="ssKFEmRNSHIYl1QP"
preference="1"
protocol="udp"
generation="0"
network="0"
type="local"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="r1"
to="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="rtp"
address="192.168.0.3"
port="4252"
preference="1"
username="LhCkgya5HMil6OHs"
protocol="udp"
generation="0"
password="EErusOJinbn98oeA"
type="local"
network="0"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="r2"
to="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="rtcp"
address="192.168.0.3"
port="4253"
preference="1"
username="+2xHg478LZxRoyXK"
protocol="udp"
generation="0"
password="3RUE2M3kFV3NJP/W"
type="local"
network="0"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="r3"
to="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="video_rtp"
address="192.168.0.3"
port="4254"
preference="1"
username="j8A7m8iqXwzyPewt"
protocol="udp"
generation="0"
password="OQHblqhXT6gJuRle"
type="local"
network="0"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="r4"
to="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="candidates"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<candidate name="video_rtcp"
address="192.168.0.3"
port="4255"
preference="1"
username="GaWnVaNbqGKmOSB1"
protocol="udp"
generation="0"
password="9+NYAZMvHo3iIUkH"
type="local"
network="0"/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="s2"
to="romeo@montague.lit/orchard"
type="result"/>
<iq from="juliet@capulet.lit/balcony"
id="s3"
to="romeo@montague.lit/orchard"
type="result"/>
<iq from="juliet@capulet.lit/balcony"
id="s4"
to="romeo@montague.lit/orchard"
type="result"/>
<iq from="juliet@capulet.lit/balcony"
id="s5"
to="romeo@montague.lit/orchard"
type="result"/>
<iq to="romeo@montague.lit/orchard"
id="r1"
from="juliet@capulet.lit/balcony"
type="result"/>
<iq to="romeo@montague.lit/orchard"
id="r2"
from="juliet@capulet.lit/balcony"
type="result"/>
<iq to="romeo@montague.lit/orchard"
id="r3"
from="juliet@capulet.lit/balcony"
type="result"/>
<iq to="romeo@montague.lit/orchard"
id="r4"
from="juliet@capulet.lit/balcony"
type="result"/>
<iq from="romeo@montague.lit/orchard"
id="r5"
to="juliet@capulet.lit/balcony"
type="set"/>
<session xmlns="http://www.google.com/session" type="accept"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<description xmlns="http://www.google.com/session/video">
<payload-type id="96" name="H264-SVC" width="320" height="200" framerate="30"/>
<payload-type id="103" name="ISAC" clockrate="16000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="97" name="IPCMWB" clockrate="16000" bitrate="80000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="99" name="speex" clockrate="16000" bitrate="22000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="102" name="iLBC" clockrate="8000" bitrate="13300" xmlns="http://www.google.com/session/phone"/>
<payload-type id="98" name="speex" clockrate="8000" bitrate="11000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="100" name="EG711U" clockrate="8000" bitrate="64000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="101" name="EG711A" clockrate="8000" bitrate="64000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="0" name="PCMU" clockrate="8000" bitrate="64000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="8" name="PCMA" clockrate="8000" bitrate="64000" xmlns="http://www.google.com/session/phone"/>
<payload-type id="106" name="telephone-event" clockrate="8000" xmlns="http://www.google.com/session/phone"/>
</description>
</session>
</iq>
<iq to="juliet@capulet.lit/balcony"
id="r5"
from="romeo@montague.lit/orchard"
type="result"/>
<iq to="juliet@capulet.lit/balcony"
id="s6"
from="romeo@montague.lit/orchard"
type="set">
<session xmlns="http://www.google.com/session"
type="terminate"
id="c1282339416"
initiator="romeo@montague.lit/orchard">
<success/>
</session>
</iq>
<iq from="juliet@capulet.lit/balcony"
id="s6"
to="romeo@montague.lit/orchard"
type="result"/>