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