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 firstname.lastname@example.org > <mailto:email@example.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 firstname.lastname@example.org. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Description: Message signed with OpenPGP using GPGMail