XMPP Server SRV Record Tutorial

With the new Openfire Version (3.7.0) released in March. I noticed a change in the S2S (federation) integration and would like to share the tips to help the setup to be done by other XMPP System Admins.

To prevent connection issue among the Servers it is required the registration of the SRV records according to the example:

In the case of the domain minhaempresa.com.br and the jabber domain to be  xmpp.minhaempresa.com.br the following records are required:

• _jabber._tcp.xmpp.minhaempresa.com.br
• _jabber._tcp.minhaempresa.com.br
• _xmpp-server._tcp.xmpp.minhaempresa.com.br
• _xmpp-server._tcp.minhaempresa.com.br

All the registration must point to your jabber domain, as noticed below:

marcelo@hellboy:~$ dig srv _xmpp-server._tcp.minhaempresa.com.br

; <<>> DiG 9.7.3 <<>> srv _xmpp-server._tcp.minhaempresa.com.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11368
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_xmpp-server._tcp.minhaempresa.com.br. IN SRV

;; ANSWER SECTION:
_xmpp-server._tcp.minhaempresa.com.br. 86297 IN SRV 0 1 5269 xmpp.minhaempresa.com.br.

;; Query time: 16 msec
;; SERVER: 200.175.5.139#53(200.175.5.139)
;; WHEN: Sun May 15 00:24:00 2011
;; MSG SIZE rcvd: 89

I've have faced this situation when migrating a customer server that was upgraded a from a previous version of Openfire. If you don't register the domain fixing SRV record, S2S functionallity will not work.

* This is an authorized translation from the Blog Mundo OpenSource written by Marcelo Terres.  Especial thanks for the great and simple guide for setting up DNS SRV records required for an XMPP server.

Jingle on Streets

It is really cool to now how many new Jingle implementers.
In Jingle Thingle 2009 I noticed that the big SIP Companies were not only just present in the meeting, but also demonstrating and testing their Jingle implementations.

We know that Google is being using Jingle on GTalk to provide Voice and File Transfers for several years, but what we don't know or maybe we didn't summarize is:
* AOL Messaging migrate to XMPP.
* Nimbuzz migrate several millions of Mobile Clients from SIP to Jingle.
* Twitter solved their scalability problems with XMPP.
* CISCO the most important SIP vendor, bought Jabber.
* OpenSER has a XMPP interoperability module.
* Asterisk has now embed support for Jingle.
* YATE has the first real full featured PBX using Jingle.
* Nokia is planning to launch a smart phone with XMPP/Jingle embeded support.

So it really seems like the simple facts that in Jingle you can negotiate several transport types, several contents in the same session opened the minds of these SIP companies to have a look on it. And the fact of Jingle in real use cases is more reliable and much easier to
implement than SIP, consolidating the protocol as the internet age multimedia signalling negotiating protocol.

Follow Jingle specification evolutions at:

XEP-0166 - Jingle
XEP-0167 - Jingle RTP Sessions
XEP-0176 - Jingle ICE-UDP Transport Method
XEP-0177 - Jingle Raw UDP Transport Method
XEP-0234 - Jingle File Transfer
XEP-0251 - Jingle Session Transfer