SIP SIMPLE Client SDK

= Gateway for Instant Messaging=

<abbr title="DesignXMPP_im, depth=2">TOC</abbr>

In XMPP there are several types of messages which lead to different semantics when exchanging XMPP ''message stanzas'' between 2 endpoints. This section focuses only on message types that allow 2 endpoints to send instant messages to each other.

Message types:

• Normal: the default message type. A reply is not expected from the recipient.
• Chat: This message type implies both parties have engaged a conversation.
• Headline: An endpoint receiving this type of message should never reply, since it's meant to be used by servers or other entities to deliver announcements.

In SIP there are currently 2 ways of doing Instant Messaging:

• SIP MESSAGE (RFC 3428)
• MSRP (RFC 4975)

The first one is session-less and the latter is session based.

The mechanisms described here follow the currently available specifications for SIP-XMPP interoperability:

• http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html
• http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html

XMPP single message <-> SIP MESSAGE

XMPP single messages are mapped directly to SIP MESSAGE requests and ''vice versa''.

Image(xmppgq_im_normal.png)

=== Overview ===

The mechanism for translating XMPP normal message stanzas and SIP MESSAGE requests is straightforward, they map one to one as stated in http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html. However, since SIP is used mainly with UDP as a transport, if a XMPP stanza is bigger than 1500 bytes it will be chunked into smaller pieces to avoid ethernet fragmentation related issues.

Since SIP MESSAGE is a non INVITE transaction, it has to be replied immediately, because there is no way to avoid retransmissions. This means that the SIP-XMPP gateway will reply on the SIP side before knowing if the message was actually delivered to the XMPP side. In order to express this a "202 Accepted" reply will be sent to the SIP request instead of a "200 OK".

On the other hand, when an XMPP stanza is translated into a SIP MESSAGE request the SIP-XMPP gateway is able to report back the result (in case of error) by using a message stanza of type ''error''. This is possible because of the asynchronous nature of stanza processing in the XMPP protocol.

Defining an XMPP chat session

In SIP a ''session'' is started by creating a dialog with the INVITE method and it's ended by terminating the dialog with a BYE request. In XMPP there is no universal mechanism to indicate that a chat session has started or ended. Because of this, the SIP-XMPP gateway will try its best to correlate the state on the SIP side with the one on the XMPP side.

There are different mechanisms by which the start and end of an XMPP chat session can be stated, but unfortunately none of them seem to be implemented in the most widely used XMPP clients, so relaying on them would lead to trouble.

• ''XEP-0155: Stanza Session Negotiation''. This XEP has been in draft form since 2008 and even if implementation is encouraged none of the widely used XMPP clients implements it.
• ''XEP-0201: Best Practices for Message Threads''. This XEP is more recent and some many clients implement it. Unfortunately, the concept of a "chat session" according to this XEP doesn't match the one on SIP because message threads last far longer, they can be resumed even after being offline for a while.