Hi Pawel,

You did not mention this, but from the log I’m concluding that the <iq/>s are
routed through a MUC. Could it be that there are multiple instances of the
same bare JID behind one nick in the MUC? I think there can some unexpected
results when routing <iq/>s in Prosody when that happens (like a result
arriving in a different instance than the one which sent it).

Thijs

> On 29 okt. 2015, at 18:02, pawel.do...@sip-communicator.org wrote:
> 
> Hi,
> 
> We have an issue where "result" packet is sometimes not routed correctly 
> between BOSH and regular client connection. The situation is that there is 
> one client connected over BOSH using Strophe.js and at the other side there 
> is Smack client connected through regular XMPP connection. Now the Smack 
> client is trying to establish Jingle session by sending 'session-initiate'. 
> Next BOSH client sends "result" and 'session-accept' in the same BOSH 
> transaction. From Prosody logs on debug level we can see that it claims to 
> have routed this packet, but in packet capture we do not see it reaching 
> Smack client(session-accept is routed correctly though). Both Smack client 
> and Prosody are on the same host and are communicating via 127.0.0.1.
> 
> Going step by step through the logs attached:
> 
> 1. On "smack_client_pcap" screenshot we can see that Smack client sends 
> "session-initiate" with ID="CkX9S-245331". XMPP dissector notices that this 
> packet is without response.
> 2. At the beginning of "prosody_debug_logs.txt" we see that Prosody is 
> sending this packet to the BOSH client on line 5: "sent private stanza to..."
> 3. In "bosh_client_logs.txt" the BOSH client receives 'session-initiate' and 
> it has different ID that original packet. I assume that there is some ID 
> translation there.
> 4. In "bosh_client_logs.txt" in "outgoing" line 106 there are both 'result' 
> and 'session-initiate' packets included in BOSH response.
> 5. Finally going back to "prosody_debug_logs.txt" we can also see that 
> Prosody claims to have routed the "result" packet at line 96. Unfortunately 
> we do not see it on Smack client side.
> 
> The situation repeats with next jingle sessions until Smack client 
> disconnects and connects to the Prosody again - after that it seems to work 
> fine. The issue can not be reproduced every time and happens rarely. Observed 
> on Ubuntu package 0.9.1-1 and on manually installed prosody-trunk 
> 1nightly575-1~trusty.
> 
> Do you have any ideas what may be causing it ?
> 
> Best regards,
> Pawel
> 
> 
> 
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "prosody-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to prosody-dev+unsubscr...@googlegroups.com 
> <mailto:prosody-dev+unsubscr...@googlegroups.com>.
> To post to this group, send email to prosody-dev@googlegroups.com 
> <mailto:prosody-dev@googlegroups.com>.
> Visit this group at http://groups.google.com/group/prosody-dev 
> <http://groups.google.com/group/prosody-dev>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> <smack_client_pcap.png><prosody_debug_logs.txt><bosh_client_logs.txt>

-- 
You received this message because you are subscribed to the Google Groups 
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to