peter,
i analyzed the pua error situation more closely. it happens when rls
has db_mode=0 and does not happen when rls has db_mode=2. presence and
pua both do not have db_mode set.
the test scenario is such where rls list sip:jh-buddies@test.fi consist
of two entries: sip:test@test.fi and sip:foo@test.fi. the former is
offline and the latter is online and has published its presence state.
the case where rls db_mode=0 goes like this.
sip:jh@test.fi rls subscribes sip:jh-buddies@test.fi, which sip proxy
routes to rls/presence server, which handles the subscribe and
(according to wireshark) replies to it with 200 ok:
Sep 9 13:36:59 siika /usr/sbin/sip-proxy[7472]: INFO: Routing SUBSCRIBE
<sip:jh-buddies@test.fi> to presence server
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7313]: INFO: Handling SUBSCRIBE
<sip:jh-buddies@test.fi>
then presence/rls server goes on and generates notify on this subscribe to
sip:jh@test.fi, which sip proxy forwards to subscriber:
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7313]: INFO: Routing locally generated NOTIFY
<sip:edxjbtay@192.98.103.10:58563;alias=192.98.103.10~59572~2;transport=tcp> to
<sip:jh@test.fi> from <sip:jh-buddies@test.fi>
Sep 9 13:36:59 siika /usr/sbin/sip-proxy[7458]: INFO: Routing in-dialog NOTIFY
<sip:edxjbtay@192.98.103.10:58563;transport=tcp> from <sip:jh-buddies@test.fi>
to <sip:192.98.103.10:59572;transport=tcp>
at this point, presence server has NOT received 200 ok to this notify
from subscriber sip:jh@test.fi yet.
then presence/rls server generates subscribe over loopback interface to
one of the entries (sip:test@test.fi) on jh-buddies list, which
presence/rls server handles, replies with 202 ok and generates notify to
itself over loopback interface:
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7313]: INFO: <core> [tcp_main.c:2787]:
quick connect for 0x7ffaa38faed0
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7313]: INFO: Routing locally generated SUBSCRIBE
<sip:test@test.fi> to <sip:test@test.fi> from <sip:jh@test.fi>
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7316]: INFO: Handling SUBSCRIBE
<sip:test@test.fi>
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7316]: INFO: Routing locally generated NOTIFY
<sip:rls@127.0.0.1:5082;transport=tcp> to <sip:jh@test.fi> from
<sip:test@test.fi>
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7316]: INFO: presence [notify.c:1581]: NOTIFY
sip:jh@test.fi via sip:rls@127.0.0.1:5082;transport=tcp on behalf of sip:test@test.fi for
event presence
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7313]: INFO: <core> [tcp_main.c:2787]:
quick connect for 0x7ffaa391c890
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7316]: INFO: Handling in-dialog NOTIFY
<sip:rls@127.0.0.1:5082;transport=tcp> from <sip:test@test.fi> to
<sip:jh@test.fi>
at this point, 200 ok to this notify has NOT been generated yet.
then wireshark shows that 200 ok arrives from sip:jh@test.fi to the
notify that presence/rls server sent to it before the above requests.
after that the error is reported to syslog:
Sep 9 13:36:59 siika /usr/sbin/pres-serv[7311]: ERROR: pua [send_subscribe.c:689]: Could
not convert temporary dialog into a dialog
i'm not sure how this matches your explanation, because i don't see any
notify received on a new dialog before 2XX to subscribe.
the pcap file is enclosed. i'll describe in next email, how things work
when rls db_mode=2.
-- juha