< draft-veikkolainen-sip-voip-xmpp-im-00.txt   draft-veikkolainen-sip-voip-xmpp-im-01.txt >
Network Working Group S. Veikkolainen Network Working Group S. Veikkolainen
Internet-Draft M. Isomaki Internet-Draft M. Isomaki
Intended status: Standards Track Nokia Intended status: Standards Track Nokia
Expires: September 5, 2009 March 4, 2009 Expires: January 11, 2010 July 10, 2009
Guidelines and Protocol Extensions for Combining SIP Based Real-time Guidelines and Protocol Extensions for Combining SIP Based Real-time
Media Sessions With XMPP Based Instant Messaging and Presence Service. Media Sessions With XMPP Based Instant Messaging and Presence Service.
draft-veikkolainen-sip-voip-xmpp-im-00 draft-veikkolainen-sip-voip-xmpp-im-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009. This Internet-Draft will expire on January 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 34 skipping to change at page 2, line 34
5.3. Using XMPP presence for publishing and obtaining SIP 5.3. Using XMPP presence for publishing and obtaining SIP
contact address, media capabilities and availability . . . 9 contact address, media capabilities and availability . . . 9
6. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 9 6. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 9
6.1. Extensions to XMPP message stanza . . . . . . . . . . . . 9 6.1. Extensions to XMPP message stanza . . . . . . . . . . . . 9
6.1.1. The <sip-contact> element . . . . . . . . . . . . . . 9 6.1.1. The <sip-contact> element . . . . . . . . . . . . . . 9
6.1.2. The <sip-correlation> element . . . . . . . . . . . . 10 6.1.2. The <sip-correlation> element . . . . . . . . . . . . 10
6.2. Extensions to XMPP presence stanza . . . . . . . . . . . . 11 6.2. Extensions to XMPP presence stanza . . . . . . . . . . . . 11
6.3. Extensions to SIP headers . . . . . . . . . . . . . . . . 11 6.3. Extensions to SIP headers . . . . . . . . . . . . . . . . 11
6.3.1. SIP XMPP-Thread header . . . . . . . . . . . . . . . . 11 6.3.1. SIP XMPP-Thread header . . . . . . . . . . . . . . . . 11
6.3.2. SIP XMPP-Contact header . . . . . . . . . . . . . . . 12 6.3.2. SIP XMPP-Contact header . . . . . . . . . . . . . . . 12
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Endpoint engaged in an IM session adds a voice/video 7.1. Endpoint engaged in an IM session adds a voice/video
component to the conversation . . . . . . . . . . . . . . 14 component to the conversation . . . . . . . . . . . . . . 14
7.2. Endpoint engaged in a SIP session adds an XMPP IM 7.2. Endpoint engaged in a SIP session adds an XMPP IM
conversation . . . . . . . . . . . . . . . . . . . . . . . 17 conversation . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 20 skipping to change at page 3, line 20
telephony features including interworking with the traditional Public telephony features including interworking with the traditional Public
Switched Telephone Network (PSTN). SIP is also gaining popularity in Switched Telephone Network (PSTN). SIP is also gaining popularity in
the field of video communication. the field of video communication.
At the same time, the Extensible Messaging and Presence Protocol At the same time, the Extensible Messaging and Presence Protocol
(XMPP) is enjoying widespread usage in instant messaging and presence (XMPP) is enjoying widespread usage in instant messaging and presence
services. An interesting scenario arises when a SIP based voice and services. An interesting scenario arises when a SIP based voice and
video service is combined together with an XMPP based instant video service is combined together with an XMPP based instant
messaging and presence service. messaging and presence service.
This memo describes how SIP based real-tome sessions and XMPP based This memo describes how SIP based real-time sessions and XMPP based
IM and presence can be offered using existing server implementations. IM and presence can be offered using existing server implementations.
This memo also presents a set of requirements and protocol extensions This memo also presents a set of requirements and protocol extensions
for SIP User Ageng and XMPP client implementations in order to offer for SIP User Agent and XMPP client implementations in order to offer
a seamless usage experience when using SIP based VoIP with XMPP based a seamless usage experience when using SIP based VoIP with XMPP based
instant messaging and presence. instant messaging and presence.
Combining SIP based real-time services with XMPP based presence and Combining SIP based real-time services with XMPP based presence and
IM service can be accomplished for the most part in the endpoints; IM service can be accomplished in the endpoints; no support is needed
little if anything needs to be done in the service infrastructure. in the service infrastructure. It is even possible to achieve
It is also possible to achieve seamless integration even when SIP and seamless integration when SIP and XMPP services are offered by
XMPP services are offered by different service providers. different service providers.
The main issues that need to be addressed when offering such combined The main issues that need to be addressed when offering such combined
services are identities and addressing. SIP and XMPP both use a services are identities and addressing. SIP and XMPP both use a
similar addressing scheme (based on "user@domain" structure) to similar addressing scheme (based on "user@domain" structure) to
identify users and endpoints but there are some subtle differencies identify users and endpoints but there are some subtle differences as
as well. It is not possible to assume any algorithmic correlation well. We do not assume any algorithmic correlation or translation
between SIP and XMPP Universal Resource Identifiers (URI), even when between SIP and XMPP Universal Resource Identifiers (URI), even when
they identify the same user or endpoint. New protocol mechanisms are they identify the same user or endpoint. New protocol mechanisms are
needed to tie together communication contexts that are based on the needed to tie together communication contexts that are based on the
two protocols. two protocols.
We do not discuss how protocol translation through a gateway could be We do not discuss how protocol translation through a gateway could be
performed between the protocols; this is the subject of other work, performed between the protocols; this is the subject of other work,
see for example [I-D.saintandre-sip-xmpp-core]. see for example [I-D.saintandre-sip-xmpp-core].
We focus on one-to-one communication only. Multiparty use cases such We focus on one-to-one communication only. Multiparty use cases such
as combining SIP voice conference with XMPP IM group chat are beyond as combining SIP voice conference with XMPP IM group chat are beyond
the scope. the scope.
The document structure is as follows: Section 2 present the document The document structure is as follows: Section 2 presents the document
conventions and definitions, Section 3 presents deployment scenarios conventions and definitions, Section 3 presents deployment scenarios
and use cases, Section 4 lists the requirements, Section 5 provides and use cases, Section 4 lists the requirements, Section 5 provides
an operview of the protocol operation, Section 6 provides the an overview of the protocol operation, Section 6 provides the
defintions, and examples are presented in Section 7. definitions, and examples are presented in Section 7.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
The following definitions are used in this memo: The following definitions are used in this memo:
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Integrated endpoint is an implementation that combines the Integrated endpoint is an implementation that combines the
functionality of SIP User Agent and XMPP client and can offer its functionality of SIP User Agent and XMPP client and can offer its
user a seamless user experience in the sense that a single UI and user a seamless user experience in the sense that a single UI and
contact information can be user for voice and video communication contact information can be user for voice and video communication
using the SIP protocol as well as instant messaging and presence using the SIP protocol as well as instant messaging and presence
sharing using XMPP. We assume an integrated endpoint is able to sharing using XMPP. We assume an integrated endpoint is able to
support SIP and XMPP protocol extensions defined in this memo. support SIP and XMPP protocol extensions defined in this memo.
Separated endpoint refers to independent SIP User Agent and XMPP Separated endpoint refers to independent SIP User Agent and XMPP
client implementations that are not aware of each other if they client implementations that are not aware of each other if they
are used by the same user. The users uses SIP UA for voice and are used by the same user. The users use SIP UA for voice and
video, while using XMPP client for IM and presence. It is assumed video, while using XMPP client for IM and presence. It is assumed
that a separated endpoint does not support any SIP or XMPP that a separated endpoint does not support any SIP or XMPP
protocol extensions defined in this memo. protocol extensions defined in this memo.
3. Deployment scenarios and use cases 3. Deployment scenarios and use cases
This section presents the assumptions we make about SIP and XMPP This section presents the assumptions we make about SIP and XMPP
deployments with respect to endpoints and server infrastructure. We deployments with respect to endpoints and server infrastructure. We
also enumerate the actual use cases that the combined service must also enumerate the actual use cases that the combined service must
accommodate for. accommodate for.
3.1. Deployment scenarios 3.1. Deployment scenarios
The assumption is that the server infrastructure for SIP and XMPP are We assume that the server infrastructures for SIP and XMPP are
totally separated, thus no exchange of information is expected totally separated, thus no exchange of information is expected
between them. There is no assumption that SIP and XMPP services are between these. We do not even assume that SIP and XMPP services are
even offered by the same service provider. This means that the user offered by the same service provider. This means that the user
identities can even be from two different domains. However, if the identities can belong to two different domains. However, if the same
same service provider offers both SIP and XMPP service, it is service provider offers both SIP and XMPP service, it is recommended
recommended that the URIs sip:user@domain and xmpp:user@domain that the URIs sip:user@domain and xmpp:user@domain correspond to the
correspond to the same user. same user.
We assume that the user intially only knows the contact address of We assume that the user initially only knows the contact address of
the other user in one protocol space. The contact address for the the other user in one protocol space. The contact address for the
other protocol must be learned through this. other protocol must be learned through this.
We consider only cases where two integrated endpoints interact. When We consider only cases where two integrated endpoints interact. When
an intergrated endpoint communicates with a separated endpoint, an integrated endpoint communicates with a separated endpoint, normal
normal SIP and XMPP procedures apply and no extensions defined in SIP and XMPP procedures apply and no extensions defined in this memo
this memo are used. are used.
3.2. Use cases 3.2. Use cases
o Two users who both use an integrated endpoint start an (XMPP) IM o Two users who both use an integrated endpoint start an (XMPP) IM
conversation. After the exchange of initial messages, their UIs conversation. After the exchange of initial messages, their UIs
show that the other party is capable of (SIP) voice and/or video show that the other party is capable of (SIP) voice and/or video
in addition to IM. Either user can at any point add voice and/or in addition to IM. Either user can at any point add voice and/or
video component to the conversation in such a way that they end up video component to the conversation in such a way that it ends up
in the same endpoint and conversation context where the IM in the same endpoint and conversation context where the IM
exchange is already taking place. (Note that for this use case exchange is already taking place. (Note that for this use case
the conversation initiatior initially only needs to know the other the conversation initiator initially only needs to know the other
user's XMPP user id.) user's XMPP user id.)
o Two users who both use an integrated endpoint start a (SIP) voice o Two users who both use an integrated endpoint start a (SIP) voice
and/or video call. As the call is established, their UIs show and/or video call. As the call is established, their UIs show
that the other party is capable for (XMPP) IM. Either user can at that the other party is capable for (XMPP) IM. Either user can at
any point add an IM component to the conversation in such a way any point add an IM component to the conversation in such a way
that they end up in the same endpoint and conversation context that it ends up in the same endpoint and conversation context
where the voice and/or call is already taking place. (Note that where the voice and/or video call is already taking place. (Note
for this use case the caller initially only needs to know the that for this use case the caller initially only needs to know the
other user's SIP user id.) other user's SIP user id.)
It is possible to vary the two cases above so that one fo the It is possible to vary the two cases above so that one of the
users initiates a "multimedia call" to the other one, i.e. SIP users initiates a "multimedia call" to the other one, i.e. SIP
voice and/or video and XMPP IM are all active from the stary. voice and/or video and XMPP IM are all active from the start.
Tehcnically this happens according to the two-phased approach Technically this happens according to the two-phased approach
above, and it inivisble from the end-user. above, and it invisible from the end-user.
o A user of an integrated endpoint is able to publish her SIP voice o A user of an integrated endpoint is able to publish her SIP voice
and video related presence status as part of her XMPP presence. and video related presence status as part of her XMPP presence.
The status includes information such as user's SIP contact address The status includes information such as user's SIP contact address
(for the integrated endpoint), media capability and availability (for the integrated endpoint), media capability and availability
and whether the user is currently "on the phone". Another user of and whether the user is currently on the phone. Another user of
an integrated endpoint can see the presence status (assuming she an integrated endpoint can see the presence status (assuming she
is authorized for that) and based on that initiate calls. For is authorized for that) and based on that initiate calls. For
instance watcher's UI can now for certainty show that the user on instance watcher's UI can now for certain show that the user on
her roster is capable of receiving "multimedia calls" (Note that her roster is capable of receiving multimedia calls. (Note that
the watcher initially only needs to know the other user's XMPP the watcher initially only needs to know the other user's XMPP
user id.) user id.)
OPEN ISSUE: Is there a use case for discovering other user's XMPP OPEN ISSUE: Is there a use case for discovering other user's XMPP
identity based on her SIP identity without needing to establish a identity based on her SIP identity without needing to establish a
media session. SIP OPTIONS would be one possibility for that (as media session. SIP OPTIONS would be one possibility for that (as
we do not assume SIP presence support). we do not assume SIP presence support).
4. Requirements 4. Requirements
This section presents the protocol requirements. This section presents the protocol requirements.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
REQ-4: It must be possible for the sender to convey in the XMPP REQ-4: It must be possible for the sender to convey in the XMPP
message information which allows the recipient to correlate message information which allows the recipient to correlate
the message with an ongoing SIP session. the message with an ongoing SIP session.
REQ-5: It must be possible to include SIP real-time media related REQ-5: It must be possible to include SIP real-time media related
contact and status in XMPP presence information. The contact and status in XMPP presence information. The
information must contain at least SIP contact address to information must contain at least SIP contact address to
identify a user or a user agent instance, media capabilities identify a user or a user agent instance, media capabilities
and general availability status and general availability status
OPEN ISSUE: Should we define requirements related to "error" or OPEN ISSUE: Should we define requirements related to error or
"corner" cases here. For instance what happens to communication corner cases here. For instance what happens to communication
attempts after the other party has closed the conversation attempts after the other party has closed the conversation
context, e.g. a correlated XMPP message that is sent after the context, e.g. a correlated XMPP message that is sent after the
related SIP session is terminated. Or a SIP INVITE that appears related SIP session is terminated. Or a SIP INVITE that appears
two days after the XMPP IM conversation was ended. two days after the XMPP IM conversation was ended.
NOTE: There is also an implicit requirement that we must take NOTE: There is also an implicit requirement that we must take
Session Border Controllers into account when defining how SIP User Session Border Controllers into account when defining how SIP User
Agents are able to identify an existing session between them in a Agents are able to identify an existing session between them in a
common manner. common manner.
5. Overview of operation 5. Overview of operation
Both SIP and XMPP allow registration of multiple endpoints using the Both SIP and XMPP allow registration of multiple endpoints using the
same identifier, either a SIP AOR or XMPP Jabber ID (JID). When two same identifier, either a SIP AOR or XMPP Jabber ID (JID). When two
endpoints are enganged in an IM conversation, for example, and wish endpoints are engaged in an IM conversation, for example, and wish to
to add a voice component to the communication, it has be ensured that add a voice component to the communication, it has to be ensured that
the resulting SIP dialog is targeted to the same endoint that is the resulting SIP dialog is targeted to the same endpoint that is
running the IM conversation. Fortunately, both XMPP and SIP provide running the IM conversation. Fortunately, both XMPP and SIP provide
a mechanism for this. a mechanism for this.
[I-D.ietf-sip-gruu] defines mechanisms for a SIP UA to obtain and use [I-D.ietf-sip-gruu] defines mechanisms for a SIP UA to obtain and use
a Globally Routable User Agent (UA) URI. A GRUU will route a call to a Globally Routable User Agent (UA) URI, or GRUU. A GRUU will route
a specific UA instance. Unfortunately, not all SIP registrars a call to a specific UA instance. Unfortunately, not all SIP
support the optional GRUU mechanism. In that case the SIP UA has not registrars support the optional GRUU mechanism. In that case the SIP
other option but to use its AOR in place of GRUU. UA has not other option but to use its AOR in place of GRUU.
In XMPP, a "full JID" consists of a name, domain and a resource In XMPP, a "full JID" consists of a name, domain and a resource
identifier in the form of <name@domain/resource>. The resource identifier in the form of <name@domain/resource>. The resource
identifier can be used to identify a specific endpoint. identifier can be used to identify a specific endpoint.
5.1. Endpoints engaged in XMPP conversation adding a SIP session 5.1. Endpoints engaged in XMPP conversation adding a SIP session
Bob Alice Bob Alice
| | | |
| IM session | | IM session |
skipping to change at page 8, line 4 skipping to change at page 8, line 4
|<----------------------| |<----------------------|
| | | |
| (F3) ACK | | (F3) ACK |
|---------------------->| |---------------------->|
| | | |
| RTP media | | RTP media |
|<=====================>| |<=====================>|
| | | |
This case starts by one endpoint (Bob) sending a message stanza to This case starts by one endpoint (Bob) sending a message stanza to
another (Alice). Bob includes <thread> element in the message and another (Alice). Bob includes a <thread> element in the message and
chooses a unique value for it. In his first message Bob also chooses a unique value for it. In his first message Bob also
includes his SIP URI in <sip-contact> element, defined in includes his SIP URI in <sip-contact> element, defined in
Section 6.1. If Bob has been able to obtain a GRUU from his Section 6.1. If Bob has been able to obtain a GRUU from his
registrar, he populates the <sip-contact> with that. Otherwise a registrar, he populates the <sip-contact> with that. Otherwise a
mere AOR is used. When Alice receives Bob's SIP URI Alice stores it mere AOR is used. When Alice receives Bob's SIP URI Alice stores it
associated with the current <thread>. When responding to Bob's associated with the current <thread>. When responding to Bob's
messages Alice also includes <thread> and her SIP URI (GRUU or AOR) messages Alice also includes a <thread> element and her SIP URI (GRUU
in <sip-contact>. Upon receiving Alice's first message Bob stores or AOR) in <sip-contact>. Upon receiving Alice's first message Bob
Alice's SIP URI associated with the current <thread>. In addition to stores Alice's SIP URI associated with the current <thread>. In
containing a SIP URI, <sip-contact> also conveys the information addition to containing a SIP URI, <sip-contact> also conveys the
whether an endpoint supports audio or video or both medias. So, information whether an endpoint supports audio or video or both
based on exchanged <sip-contact> elements, both endpoints now know medias. So, based on exchanged <sip-contact> elements, both
each others SIP URIs and media capabilities. endpoints now know each others SIP URIs and media capabilities.
The same <thread> value is used in all further messages by both The same <thread> value is used in all further messages by both
endpoints to keep track of the conversation. As long as the <thread> endpoints to keep track of the conversation. As long as the <thread>
value is unchanged, the <sip-contact> element need not be repeated, value is unchanged, the <sip-contact> element need not be repeated,
unless either endpoint's SIP GRUU changes for some reason. unless either endpoint's SIP GRUU changes for some reason.
When either party wants to extend the IM conversation by adding SIP When either party wants to extend the IM conversation by adding SIP
voice or video session, they address a SIP INVITE to the SIP URI voice or video session, they address a SIP INVITE to the SIP URI
learned in <sip-contact>. If <contact> contained a GRUU, it ensures learned in <sip-contact>. If the <sip-contact> element contained a
that the INVITE will be routed to the correct endpoint. The caller GRUU, it ensures that the INVITE will be routed to the correct
populates XMPP-Thread header, defined in Section 6.3.1, in the INVITE endpoint. The caller populates an XMPP-Thread header, defined in
with the value of <thread>. The callee is thus able to correlate the Section 6.3.1, in the INVITE with the value of <thread>. The callee
SIP session to the IM conversation. The callee replays XMPP-Thread is thus able to correlate the SIP session to the IM conversation.
in responses to INVITE to indicate that the correlation was The callee replays XMPP-Thread in responses to INVITE to indicate
successful. that the correlation was successful.
5.2. Endpoints engaged in a SIP session adding an XMPP IM conversation 5.2. Endpoints engaged in a SIP session adding an XMPP IM conversation
In this case two endpoints first have a SIP voice or video session. In this case two endpoints first have a SIP voice or video session.
They exchange their full JIDs within the session establishment. The They exchange their full JIDs within the session establishment: the
caller (Bob) adds XMPP-Contact header, defined in Section 6.3.2, in caller (Bob) adds XMPP-Contact header, defined in Section 6.3.2, in
INVITE populating it with his full JID. XMPP-Contact also includes INVITE populating it with his full JID. XMPP-Contact also includes
an opaque end-to-end identifier for the session common to both an opaque end-to-end identifier for the session common to both
endpoints. The callee (Alice) stores this information as part of the endpoints. The callee (Alice) stores this information as part of the
session state. In 200 OK response to INVITE Alice includes similar session state. In 200 OK response to INVITE Alice includes similar
XMPP-Contact header with her full JID, and replays the end-to-end XMPP-Contact header with her full JID, and replays the end-to-end
session identifier. Bob stores this information as part of his session identifier. Bob stores this information as part of his
session state. Both endpoints now know each others full JIDs and session state. Both endpoints now know each others full JIDs and
have a common reference to the session. have a common reference to the session.
skipping to change at page 9, line 15 skipping to change at page 9, line 15
[I-D.kaplan-sip-session-id] defines a Session-ID header that [I-D.kaplan-sip-session-id] defines a Session-ID header that
potentially could also be used. potentially could also be used.
When either endpoint wants to send XMPP messages to each other, they When either endpoint wants to send XMPP messages to each other, they
address them to the full JID learned from XMPP-Contact header. This address them to the full JID learned from XMPP-Contact header. This
ensures that the messages reach the correct endpoint. In the very ensures that the messages reach the correct endpoint. In the very
first message the sender also includes <sip-correlation> element, first message the sender also includes <sip-correlation> element,
defined in Section 6.1, with the session identifier value learned defined in Section 6.1, with the session identifier value learned
from XMPP-Contact. The recipient uses the value to correlate the from XMPP-Contact. The recipient uses the value to correlate the
message with the SIP session and echoes it back the first message it message with the SIP session and echoes it back the first message it
sends to indicate that the correlation was succesful. sends to indicate that the correlation was successful.
5.3. Using XMPP presence for publishing and obtaining SIP contact 5.3. Using XMPP presence for publishing and obtaining SIP contact
address, media capabilities and availability address, media capabilities and availability
SIP related presence information is encoded in XMPP presence schema SIP related presence information is encoded in XMPP presence schema
as an extension. It includes endpoints SIP URI (preferably GRUU but as an extension. It includes endpoints SIP URI (preferably GRUU but
can be also AOR), media capabilities (audio, video), and availability can be also AOR), media capabilities (audio, video), and availability
(open, closed, busy). Based on this information XMPP Presence (open, closed, busy). Based on this information XMPP Presence
watcher is able to initiate SIP voice and video sessions. watcher is able to initiate SIP voice and video sessions.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
6.1. Extensions to XMPP message stanza 6.1. Extensions to XMPP message stanza
The child elements of the message stanza can be extended with The child elements of the message stanza can be extended with
elements from other namespaces. For the purposes of carrying a SIP elements from other namespaces. For the purposes of carrying a SIP
identifier in the message stanza, we define two new elements, the identifier in the message stanza, we define two new elements, the
<sip-contact> element and <sip-correlation> element. <sip-contact> element and <sip-correlation> element.
6.1.1. The <sip-contact> element 6.1.1. The <sip-contact> element
The <sip-contact> element, qualified by The <sip-contact> element, qualified by urn:xmpp:sip-contact
"http://jabber.org/protocol/sip-contact" namespace, has one mandatory namespace, has one mandatory attribute, "target", which defines the
attribute, "target", which defines the target's SIP URI. The format target's SIP URI. The format of the "target" attribute is an
of the "target" attribute is an absoluteURI defined in [RFC3261]. absoluteURI defined in [RFC3261].
When an endpoint initiates an XMPP IM conversation, and wants to When an endpoint initiates an XMPP IM conversation, and wants to
offer a possibility to later add a SIP real-time media session, it offer a possibility to later add a SIP real-time media session, it
MUST include a <sip-contact> element as a child element in the first MUST include a <sip-contact> element as a child element in the first
the <message> stanza it sends, and MUST add a <thread> element and the <message> stanza it sends, and MUST add a <thread> element and
populate its value according to [RFC3921]. The endpoint MUST include populate its value according to [RFC3921]. The endpoint MUST include
in the "target" attribute of the <sip-contact> element the SIP URI it in the "target" attribute of the <sip-contact> element the SIP URI it
wishes to be contacted at. If the endpoint is aware of its GRUU, it wishes to be contacted at. If the endpoint is aware of its GRUU, it
SHOULD use that as the value in the "target" attribute; otherwise it SHOULD use that as the value in the target attribute; otherwise it
MAY use its AOR. MAY use its AOR.
The endpoint receiving an XMPP <message> stanza that includes The endpoint receiving an XMPP <message> stanza that includes
<thread> and <sip-contact> elements MUST copy the <thread> element <thread> and <sip-contact> elements MUST copy the <thread> element
value to the first <message> stanza it sends back, as defined in value to the first <message> stanza it sends back, as defined in
[RFC3921], and MUST include a <sip-contact> element and set the [RFC3921], and MUST include a <sip-contact> element and set the
"target" attribute value to the SIP URI it wishes to be contacted at. "target" attribute value to the SIP URI it wishes to be contacted at.
An endpoint MUST add its audio and video capabilities defined in An endpoint MUST add its audio and video capabilities defined in
[RFC3840] to the contact address in the "target" attribute, and MUST [RFC3840] to the contact address in the "target" attribute, and MUST
skipping to change at page 10, line 26 skipping to change at page 10, line 26
An endpoint MAY add other media capabilities. An endpoint MAY add other media capabilities.
When an endpoint receives a <sip-contact> element in a <message> When an endpoint receives a <sip-contact> element in a <message>
stanza, it MUST store the value of the target attribute, and use it stanza, it MUST store the value of the target attribute, and use it
as the SIP URI in an INVITE request if the user of the endpoint would as the SIP URI in an INVITE request if the user of the endpoint would
like to add a SIP session to the IM conversation context like to add a SIP session to the IM conversation context
For example, a <sip-contact> element carrying a SIP Globally Routable For example, a <sip-contact> element carrying a SIP Globally Routable
Unique URI (GRUU) would be Unique URI (GRUU) would be
<sip-contact target="<sip:alice@example.com">;gr=urn: <sip-contact target='&#x55;sip:alice@example.com;
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
audio;video"> audio;video&#x57'>
6.1.2. The <sip-correlation> element 6.1.2. The <sip-correlation> element
In order to indicate that an XMPP IM conversation is related to an In order to indicate that an XMPP IM conversation is related to an
existing SIP session, we define a new element in the message stanza existing SIP session, we define a new element in the message stanza
called <sip-correlation>. The <sip-correlation>, qualified by the called <sip-correlation>. The <sip-correlation>, qualified by the
"http://jabber.org/protocol/sip-correlation" namespace, has one urn:xmpp:sip-correlation namespace, has one mandatory attribute,
mandatory attribute, "value". "value".
The endpoint sending the <message> stanza MUST set the "value" The endpoint sending the <message> stanza MUST set the "value"
attribute to the value of the correlation-value parameter of the SIP attribute to the value of the correlation-value parameter of the SIP
XMPP-Contact header. The XMPP-Contact header is exhanged during the XMPP-Contact header, defined in Section 6.3.2. The XMPP-Contact
setup of the SIP session. The endpoint MUST also include a <thread> header is exchanged during the setup of the SIP session.
element in the message.
An endpoint receiving a <message> stanza which includes a <sip- An endpoint receiving a <message> stanza which includes a <sip-
correlation> element MUST first compare the "from" attribute value of correlation> element MUST first compare the "from" attribute value of
the <message> stanza to the XMPP JID in the contact-value of the the <message> stanza to the XMPP JID in the contact-value of the
XMPP-Contact header of its active SIP sessions. If a matching SIP XMPP-Contact header of its active SIP sessions. If a matching SIP
session is found, the endpoint MUST compare the "value" attribute to session is found, the endpoint then MUST compare the "value"
the correlation-value of the XMPP-Contact header of that SIP session. attribute of the <sip-correlation> element to the correlation-value
If the "value" attribute matches to correlation-value of an XMPP- of the XMPP-Contact header of that SIP session. If the "value"
Contact header, the <message> stanza is correlated to that SIP attribute matches to correlation-value of an XMPP-Contact header, the
session. If the user replies to the message, the values of the <message> stanza is correlated to that SIP session. If the user
<thread> element and the "value" attribute of the <sip-correlation> replies to the message, the values of the <thread> element and the
element in the first reply MUST be the same as in the original "value" attribute of the <sip-correlation> element in the first reply
message. This indicates that the correlation was successful. The MUST be the same as in the original message. This indicates that the
correlation is valid as long as the messages are exchanged with the correlation was successful. The correlation is valid as long as the
same <thread> value. messages are exchanged with the same <thread> value.
As an example, a <sip-correlation> element carrying the XMPP-Contact As an example, consider a case where a SIP session was set up, and
header correlation-value parameter of an existing SIP session would during that time one of the endpoints included a XMPP-Contact header
be with the correlation-value parameter set to the value 'xyz123'. Now,
when the same endpoint wishes to add an XMPP IM session, it would add
a <sip-correlation> element in the message stanza carrying the same
value in the "value" attribute:
<sip-correlation value="xyz123"/> <sip-correlation value='xyz123'/>
OPEN ISSUE: XML Schemas to be provided OPEN ISSUE: XML Schemas to be provided
6.2. Extensions to XMPP presence stanza 6.2. Extensions to XMPP presence stanza
The XMPP presence stanza defined in [RFC3921] can be extended with The XMPP presence stanza defined in [RFC3921] can be extended with
any properly-namespaced child element. We define a new optional any properly-namespaced child element. We define a new optional
element called <contact> which, qualified by the element called <contact> which, qualified by the urn:xmpp:contact
http://jabber.org/protocol/contact namespace, MAY appear as a child namespace, MAY appear as a child element in the presence stanza.
element in the presence stanza.
The contact element SHOULD be set to the SIP address (GRUU or AOR) The contact element SHOULD be set to the SIP address (GRUU or AOR)
the endpoint wishes to be contacted at for further communication. the endpoint wishes to be contacted at for further communication.
Exact syntax and XML Schema of the correlation element is TBD. Exact syntax and XML Schema of the correlation element is TBD.
6.3. Extensions to SIP headers 6.3. Extensions to SIP headers
6.3.1. SIP XMPP-Thread header 6.3.1. SIP XMPP-Thread header
In order to indicate that the SIP dialog is related to an existing In order to indicate that the SIP dialog is related to an existing
XMPP messaging session, we define a new SIP header, called XMPP- XMPP messaging session, we define a new SIP header, called XMPP-
Thread. The XMPP-Thread contains information that can be used by the Thread. The XMPP-Thread contains information that can be used by the
terminating endpoint to correlate the SIP session establishment to an terminating endpoint to correlate the SIP session establishment to an
existing XMPP conversation. existing XMPP conversation.
The endpoint sending a SIP INVITE request MUST include an XMPP-Thread The endpoint sending a SIP INVITE request MUST include an XMPP-Thread
header, and set its value to the value of the <thread> element used header, and set its value to the value of the <thread> element used
in the XMPP IM conversation. in the XMPP IM conversation.
The endpoint receiving a SIP INVITE which inludes an XMPP-Thread The endpoint receiving a SIP INVITE which includes an XMPP-Thread
header act as follows: header acts as follows:
o it first compares the Contact header value with all SIP GRUUs from o it first compares the Contact header value with all SIP GRUUs from
<sip-contact> elements in active XMPP IM conversations, and unless <sip-contact> elements in active XMPP IM conversations, and unless
a match is found, a match is found,
o compares P-Asserted-Identity header value with all other SIP URIs o compares P-Asserted-Identity header value with all other SIP URIs
from <sip-contact> elements in active XMPP IM conversations from <sip-contact> elements in active XMPP IM conversations
o if a single match is found, the receiving endpoint MUST the value o if a single match is found, the receiving endpoint MUST compare
of the XMPP-Thread element to the <thread> element values of the value of the XMPP-Thread element to the <thread> element
existing XMPP IM conversations the endpoint has active, and values of existing XMPP IM conversations the endpoint has active,
and
o if the value matches, the SIP INVITE is correlated to the IM o if the value matches, the SIP INVITE is correlated to the IM
conversation. The endpoint MUST copy the XMPP-Thread header to conversation. The endpoint MUST copy the XMPP-Thread header to
any of the 2xx series responses. any of the 2xx series responses.
Figure 1 defines support of XMPP-Contact header in SIP requests and Figure 1 defines support of XMPP-Contact header in SIP requests and
responses, and extends Table 2 of [RFC3261]. MESSAGE, SUBCRIBE and responses, and extends Table 2 of [RFC3261]. MESSAGE, SUBCRIBE and
NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in
[RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and [RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and
[RFC3903], respectively. [RFC3903], respectively.
skipping to change at page 12, line 48 skipping to change at page 13, line 4
thread-value = token thread-value = token
;defined in RFC3261 ;defined in RFC3261
6.3.2. SIP XMPP-Contact header 6.3.2. SIP XMPP-Contact header
The XMPP-Contact header is used to carry the XMPP JID and an opaque The XMPP-Contact header is used to carry the XMPP JID and an opaque
token that can be used for correlation purposes. token that can be used for correlation purposes.
When an endpoint initiates a SIP session, and wants to offer the When an endpoint initiates a SIP session, and wants to offer the
possibility to later add an XMPP IM conversation, it MUST include an possibility to later add an XMPP IM conversation, it MUST include an
XMPP-Contact header in the intitial SIP request. The contact-value XMPP-Contact header in the initial SIP request. The contact-value of
of the XMPP-Contact header MUST be set to the full XMPP JID the the XMPP-Contact header MUST be set to the full XMPP JID the endpoint
endpoint wishes to be contacted at, and the correlation-value SHOULD wishes to be contacted at, and the correlation-value SHOULD be set to
be set to the value of the Call-ID of the SIP session. If the the value of the Call-ID of the SIP session. If the Call-ID cannot
Call-ID cannot be used, the endpoint MUST select the correlation- be used, the endpoint MUST select the correlation-value such that it
value such that it fulfills the same uniqueness requirements defined fulfills the same uniqueness requirements defined for Call-ID in
for Call-ID in Section 8.1.1.4 of [RFC3261]. Section 8.1.1.4 of [RFC3261].
An endpoint sending a 2xx series response to an INVITE that contains An endpoint sending a 2xx series response to an INVITE that contains
XMPP-Contact header MUST include a XMPP-Contact header in the XMPP-Contact header MUST include a XMPP-Contact header in the
response, MUST set the contact-value of the header to the full XMPP response, MUST set the contact-value of the header to the full XMPP
JID the endpoint wishes to be contacted at, and MUST copy the JID the endpoint wishes to be contacted at, and MUST copy the
correlation-value from the INVITE to the 2xx response. correlation-value from the INVITE to the 2xx response.
The endpoint receiving a SIP request or response with an XMPP-Contact The endpoint receiving a SIP request or response with an XMPP-Contact
header, MUST store the value of the correlation-value in order to be header, MUST store the value of the correlation-value as part of the
able to later correlate an XMPP IM conversation with the SIP session. session state in order to be able to later correlate an XMPP IM
conversation with the SIP session.
An endpoint initiating a correlated XMPP IM conversation MUST use the
correlation-value in the <sip-correlation> element as specified in
Section 6.1.2.
Figure 2 defines support of XMPP-Contact header in SIP requests and Figure 2 defines support of XMPP-Contact header in SIP requests and
responses, and extends Table 2 of [RFC3261]. MESSAGE, SUBCRIBE and responses, and extends Table 2 of [RFC3261]. MESSAGE, SUBCRIBE and
NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined in
[RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and [RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], and
[RFC3903], respectively. [RFC3903], respectively.
Header field where proxy ACK BYE CAN INV OPT REG MSG Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- --- ------------ ----- ----- --- --- --- --- --- --- ---
XMPP-Contact R - - - o - - - XMPP-Contact R - - - o - - -
skipping to change at page 14, line 33 skipping to change at page 14, line 35
| | | |
| RTP media | | RTP media |
|<=====================>| |<=====================>|
| | | |
SIP voice session added to XMPP IM conversation SIP voice session added to XMPP IM conversation
Bob and Alice are engaged in an XMPP IM session, when Bob would like Bob and Alice are engaged in an XMPP IM session, when Bob would like
to add voice/video component to the discussion. to add voice/video component to the discussion.
When Bob and Alice exhange message stanzas, they also include the SIP When Bob and Alice exchange message stanzas, they also include the
address they would like to be contacted at. In this example, Bob is SIP address they would like to be contacted at. In this example, Bob
aware of its GRUU, while Alice is merely aware of her SIP AOR. Both is aware of its GRUU, while Alice is merely aware of her SIP AOR.
include the SIP identifier in a contact element in the message Both include the SIP identifier in a contact element in the message
stanza. stanza.
<message <message
to='alice@example.net' to='alice@example.net'
from='bob@domain.com/Home' from='bob@domain.com/Home'
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Hi!</body> <body>Hi!</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<sip-contact target="<sip:bob@domain.com">;gr=urn: <sip-contact target='&#x55;sip:bob@domain.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
audio;video" audio;video&#x57;'
xmlns="http//jabber.org/protocol/contact"/> xmlns=urn:xmpp:sip-contact/>
</message> </message>
(F1) Bob sends a message stanza to (F1) Bob sends a message stanza to
Alice Alice
In the above message, Bob includes his GRUU, and also the media In the above message, Bob includes his GRUU, and also the media
capabilities Bob is capable of handling (audio and video). capabilities Bob is capable of handling (audio and video).
Alice sends back a message stanza containing her SIP contact Alice sends back a message stanza containing her SIP contact
information. information.
<message <message
to='bob@domain.com/Home' to='bob@domain.com/Home'
from='alice@example.net/4FIL45729' from='alice@example.net/4FIL45729'
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Hello there!</body> <body>Hello there!</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<sip-contact target="<sip:alice@example.net">;audio;video" <sip-contact target='&#x55;sip:alice@example.net&#x57;audio;video'
xmlns="http//jabber.org/protocol/contact"/> xmlns=urn:xmpp:sip-contact/>
</message> </message>
(F2) Alice sends a message stanza to (F2) Alice sends a message stanza to
Bob Bob
Bob then decides to add SIP voice call to the existing XMPP Bob then decides to add SIP voice call to the existing XMPP
conversation. He picks up Alice's contact information that Alice conversation. He picks up Alice's contact information that Alice
sent to him in a message stanza, and issues a SIP INVITE request to sent to him in a message stanza, and issues a SIP INVITE request to
that URI. The XMPP-Thread carries the value of the <thread> element. that URI. The XMPP-Thread carries the value of the <thread> element.
INVITE sip:alice@example.net SIP/2.0 INVITE sip:alice@example.net SIP/2.0
Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100 Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100
Max-Forwards: 70 Max-Forwards: 70
To: Alice <sip:alice@example.com> To: Alice <sip:alice@example.com>
From: Bob <sip:bob@domain.com>;tag=18593756298 From: Bob <sip:bob@domain.com>;tag=18593756298
Call-ID: a84b4c76e66710@ua-991.domain.com Call-ID: a84b4c76e66710@ua-991.domain.com
CSeq: 314159 INVITE CSeq: 314159 INVITE
XMPP-Thread:e0ffe42b28561960c6b12b944a092794b9683a38 XMPP-Thread:e0ffe42b28561960c6b12b944a092794b9683a38
Contact: "<sip:bob@domain.com">;gr=urn: Contact: <sip:bob@domain.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
audio;video" audio;video>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(SDP not shown) (SDP not shown)
(F3) Bob sends a SIP INVITE to (F3) Bob sends a SIP INVITE to
Alice Alice
Alice responds with 200OK accepting the session invitiation request. Alice responds with 200 OK accepting the session invitation request.
Alice also includes the XMPP-Thread element to indicate that she has Alice also includes the XMPP-Thread element to indicate that she has
received the thread and successfully correlated the session received the thread and successfully correlated the session
invitation to the XMPP conversation. invitation to the XMPP conversation.
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP p1.example.com Via: SIP/2.0/UDP p1.example.com
;branch=z9hG4bKnashds8;received=192.0.2.3 ;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP p1.domain.com Via: SIP/2.0/UDP p1.domain.com
;branch=z9hG4bKnashds8;received=192.0.2.2 ;branch=z9hG4bKnashds8;received=192.0.2.2
Via: SIP/2.0/UDP ua-991.domain.com Via: SIP/2.0/UDP ua-991.domain.com
skipping to change at page 17, line 43 skipping to change at page 17, line 43
INVITE sip:alice@example.net SIP/2.0 INVITE sip:alice@example.net SIP/2.0
Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100 Via: SIP/2.0/UDP ua-991.domain.com;branch=apo92hgb2k100
Max-Forwards: 70 Max-Forwards: 70
To: Alice <sip:alice@example.com> To: Alice <sip:alice@example.com>
From: Bob <sip:bob@domain.com>;tag=18593756298 From: Bob <sip:bob@domain.com>;tag=18593756298
Call-ID: a84b4c76e66710@ua-991.domain.com Call-ID: a84b4c76e66710@ua-991.domain.com
CSeq: 314159 INVITE CSeq: 314159 INVITE
XMPP-contact:<xmpp:bob@domain.com/home> XMPP-contact:<xmpp:bob@domain.com/home>
;a84b4c76e66710@ua-991.domain.com ;a84b4c76e66710@ua-991.domain.com
Contact: "<sip:bob@domain.com">;gr=urn: Contact: <sip:bob@domain.com;gr=urn:
uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
audio;video" audio;video>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
(SDP not shown) (SDP not shown)
(F1) Bob sends a SIP INVITE to (F1) Bob sends a SIP INVITE to
Alice Alice
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP p1.example.com Via: SIP/2.0/UDP p1.example.com
;branch=z9hG4bKnashds8;received=192.0.2.3 ;branch=z9hG4bKnashds8;received=192.0.2.3
skipping to change at page 18, line 37 skipping to change at page 18, line 37
(F2) Alice accepts the session and sends a 200OK (F2) Alice accepts the session and sends a 200OK
to Bob to Bob
<message <message
to='alice@example.net' to='alice@example.net'
from='bob@domain.com/Home' from='bob@domain.com/Home'
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Hi!</body> <body>Hi!</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<sip-correlation value="a84b4c76e66710@ua-991.domain.com"> <sip-correlation value='a84b4c76e66710@ua-991.domain.com'>
</message> </message>
(F4) Bob sends a message to (F4) Bob sends a message to
Alice Alice
Alice sends back a message stanza copying the sip-correlation value Alice sends back a message stanza copying the sip-correlation value
indicating the the correlation was successful. indicating the the correlation was successful.
<message <message
to='bob@domain.com/Home' to='bob@domain.com/Home'
from='alice@example.net' from='alice@example.net'
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Hello there!</body> <body>Hello there!</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<sip-correlation value="a84b4c76e66710@ua-991.domain.com"> <sip-correlation value='a84b4c76e66710@ua-991.domain.com'>
</message> </message>
(F5) Alice sends a message stanza to (F5) Alice sends a message stanza to
Bob Bob
8. IANA Considerations 8. IANA Considerations
TBD TBD
9. Security Considerations 9. Security Considerations
The contact and correlation iformation is sensitive and we need to The contact and correlation information is sensitive and we need to
prevent connection hijacking and impersonation. If the contact prevent connection hijacking and impersonation. If the contact
information that is sent over one protocol is forged, the identity information that is sent over one protocol is forged, the identity
verification mechanism in the other no longer help as an attacker is verification mechanism in the other no longer help as an attacker is
able to assert the false identity. able to assert the false identity.
10. Acknowledgments 10. Acknowledgments
TBD TBD
11. References 11. References
skipping to change at page 20, line 49 skipping to change at page 20, line 49
11.2. Informative References 11.2. Informative References
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[I-D.kaplan-sip-session-id] [I-D.kaplan-sip-session-id]
Kaplan, H., "A Session Identifier for the Session Kaplan, H., "A Session Identifier for the Session
Initiation Protocol (SIP)", draft-kaplan-sip-session-id-01 Initiation Protocol (SIP)", draft-kaplan-sip-session-id-02
(work in progress), November 2008. (work in progress), March 2009.
[I-D.saintandre-sip-xmpp-core] [I-D.saintandre-sip-xmpp-core]
Saint-Andre, P., Houri, A., and J. Hildebrand, Saint-Andre, P., Houri, A., and J. Hildebrand,
"Interworking between the Session Initiation Protocol "Interworking between the Session Initiation Protocol
(SIP) and the Extensible Messaging and Presence Protocol (SIP) and the Extensible Messaging and Presence Protocol
(XMPP): Core", draft-saintandre-sip-xmpp-core-00 (work in (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in
progress), January 2008. progress), March 2009.
Authors' Addresses Authors' Addresses
Simo Veikkolainen Simo Veikkolainen
Nokia Nokia
P.O. Box 407 P.O. Box 407
NOKIA GROUP, FI 00045 NOKIA GROUP, FI 00045
Finland Finland
Phone: +358 50 486 4463 Phone: +358 50 486 4463
 End of changes. 58 change blocks. 
142 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/