Re: [Serusers] SER pre-release - Presence and NOTIFY

If I got it right, your problem is that your SER acting like a proxy does not "feel" it is responsible for the NOTIFY originated at your SER acting like a presence server and tries to route it by RURI, which is in this case a private IP, leading to routing failure. I also figure that your proxy server is bound to a public IP - otherwise the proxy would correctly handle the forwarding - and you have (some) clients behind NAT. In this case, the best solution might not be fixing the RURI the way you want*. With the latest (prerelease) version of SER you could try a solution like: - handle the NAT case at the SER that is contacted first by your clients - your proxy; check iptel's site for how to do this; what's most important is that the REGISTER leaves from proxy to presence server having the "received" RURI parameter attached. - presence server attaches "back" this parameter to NOTIFY's RURI (<<modparam("registrar", "received_to_uri", 1)>>). - instruct SER proxy to forward the NOTIFY based on this "received" parameter (&lt;&lt;xlset_destination(&quot;%(a)ruri.params[\&quot;received\&quot;]&quot;)&gt;&gt;)received\"]")>>). [this is a genuine new Ottendorf feature**; find it in 'avp' module]. Hth, Bogdan. * because: SER simply inserts into RURI the binding address for the AOR - and this is the correct thing to do. This AOR (sip:444@sip.xx.com) is what the subscriber inserted into the To header at registering time. The binding address (sip:444@10.1.1.1:12321) is what the subscriber inserted into Contact header at registering time. Most of the clients don't even ask you want to insert as Contact (and well they do) and simply put their IPs there or the gateway's IP if STUN capable. Unless you run yet another registrar on the proxy, SER would still not know where to forward the NOTIFY. In case you do, both proxy and presence servers would lookup the binding for AOR, which is performance unwise; moreover in case of multiple bindings for an AOR you might end up staring n^2 transactions on the proxy and n NOTIFYs received by subscriber. ** current implementation remained broken: you need to apply the patch for bug #125. SER LIST wrote: -- Bogdan Pintea iptego GmbH - VoIP Security http://www.iptego.de