xmpp-info cannot extract information when version scan is used

[fbexiga]

When using the 'xmpp-info' NSE script, the correct behaviour is for the script to be able to extract information like this:

$ sudo nmap --script 'xmpp-info' -p 5222 123.103.21.237

Starting Nmap 7.12 ( https://nmap.org ) at 2016-08-30 17:24 WEST
Nmap scan report for 123.103.21.237-BJ-CNC (123.103.21.237)
Host is up (0.28s latency).
PORT     STATE SERVICE
5222/tcp open  xmpp-client
| xmpp-info:
|   Ignores server name
|   info:
|     xmpp:
|       lang: ru-RU
|       server name: spark-chat.ecaddy.com.cn
|       version: 1.0
|     capabilities:
|
|     features:
|       In-Band Registration
|     compression_methods:
|       zlib
|     auth_mechanisms:
|       Non-SASL
|       ANONYMOUS
|       DIGEST-MD5
|       PLAIN
|       JIVE-SHAREDSECRET
|       CRAM-MD5
|   pre_tls:
|     xmpp:
|
|     capabilities:
|
|     features:
|       TLS
|   post_tls:
|     xmpp:
|
|_    capabilities:

Nmap done: 1 IP address (1 host up) scanned in 7.01 seconds

However, when using this script together with the version scan, the script cannot extract information:

$ sudo nmap -sV --script 'xmpp-info' -p 5222 123.103.21.237

Starting Nmap 7.12 ( https://nmap.org ) at 2016-08-30 17:26 WEST
Nmap scan report for 123.103.21.237-BJ-CNC (123.103.21.237)
Host is up (0.27s latency).
PORT     STATE SERVICE VERSION
5222/tcp open  jabber  Ignite Realtime Openfire Jabber server
| xmpp-info:
|   STARTTLS Failed
|   info:
|     unknown:
|
|     errors:
|       invalid-namespace
|       (timeout)
|     xmpp:
|       server name: spark-chat.ecaddy.com.cn
|       version: 1.0
|     stream_id: M8bGw
|     auth_mechanisms:
|
|     compression_methods:
|
|     features:
|
|_    capabilities:

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 32.24 seconds

By taking a look at a packet capture with Wireshark, this is how the communication looks using only the NSE script:

And this is how it looks when using the version scan as well:

It would appear that the server's changes when probing for information after the version scan, as if during the version scan, some probe is triggering this behaviour. Any way that this can be fixed?