Hey Daniel,
This time I will have to take back my thoughts about the module not
being in "stable" status ;).
By using debug=3 I could see the reason of the subscribes not being
generated (still could be good to have some error on xmpp side back,
but I can live with that for now).
The problem was
Hello,
to, from and type attributes are there, just that the uris are not the
format expected. Can you send the log messages for debug=3?
Cheers,
Daniel
On Sat, Mar 10, 2012 at 12:29 PM, Dan-Cristian Bogos <
danb.li...@googlemail.com> wrote:
> Hey Daniel,
>
> Here is the subscription coming fr
Hey Daniel,
Here is the subscription coming from OpenFIRE towards Kamailio when
the user is added in the roster on XMPP side:
"""
T 2012/03/02 09:49:57.743750 127.0.0.1:5275 -> 127.0.0.1:49965 [AP]
http://jabber.org/protocol/caps";
ext="voice-v1 video-v1 camera-v1 " hash="sha-1"
node="http://jits
Hello,
mqybe is faster to fix the handling of subscriptions from openfire. Can you
get the xmpp request with ngrep and paste it here -- maybe it is easy to
find and fix the reason the parser in xmpp module fails to understand it.
I guess pua_xmpp has to know the dialog for the mapping between the
Guys,
After my previous discovered issue (Kamailio not happy to talk with
Openfire for subscriptions), trying to find work arounds, thought
about using pua_mi to enforce subscriptions coming from XMPP side.
The following events happen:
* I subscribe over mi interface successfully.
* Presence se
