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-budd...@test.fi consist of two entries: sip:t...@test.fi and sip:f...@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:j...@test.fi rls subscribes sip:jh-budd...@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-budd...@test.fi> to presence server Sep 9 13:36:59 siika /usr/sbin/pres-serv[7313]: INFO: Handling SUBSCRIBE <sip:jh-budd...@test.fi> then presence/rls server goes on and generates notify on this subscribe to sip:j...@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:j...@test.fi> from <sip:jh-budd...@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-budd...@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:j...@test.fi yet. then presence/rls server generates subscribe over loopback interface to one of the entries (sip:t...@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:t...@test.fi> to <sip:t...@test.fi> from <sip:j...@test.fi> Sep 9 13:36:59 siika /usr/sbin/pres-serv[7316]: INFO: Handling SUBSCRIBE <sip:t...@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:j...@test.fi> from <sip:t...@test.fi> Sep 9 13:36:59 siika /usr/sbin/pres-serv[7316]: INFO: presence [notify.c:1581]: NOTIFY sip:j...@test.fi via sip:rls@127.0.0.1:5082;transport=tcp on behalf of sip:t...@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:t...@test.fi> to <sip:j...@test.fi> at this point, 200 ok to this notify has NOT been generated yet. then wireshark shows that 200 ok arrives from sip:j...@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
pcap1.pcap
Description: rls test with rls db_mode=0
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
