Ok.<br><br>I found out the "problem", there was a missing NAT handling of the responses, and the 200 OK response updated the target dialog with a non-routable IP. That's why further messages had the wronf Req-URI.
<br><br>Thanks for your pointers,<br>sam.<br><br><div><span class="gmail_quote">2007/8/2, Vaclav Kubart <<a href="mailto:vaclav.kubart@iptel.org">vaclav.kubart@iptel.org</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Samuel,<br>Maxim Sobolev was fighting with NAT and presence some time ago.<br><br>I was trying to allow calling script route block when sending NOTIFY to<br>allow its modifications, but I had not enough time to get results.
<br><br>The NOTIFY should be constructed according RFC 3261; the request URI<br>should be the value from Contact of the SUBSCRIBE request (if only loose<br>routers in routes appear).<br><br>To, From, Via and routes should follow RFC 3261 too.
<br><br>Contact header value is the address at which the SUBSCRIBE request<br>arrives to the server (according examples in RFC 3856, this is<br>controversial but possible).<br><br>Modifying of async_auth_queries should have no influence on sent
<br>NOTIFYs. If does, it is probably a bug.<br><br>All headers you mentioned are derived from dialog initiating SUBSCRIBE<br>request as RFC says.<br><br> Vaclav<br><br>On Čt, srp 02, 2007 at 12:05:02 +0200, samuel wrote:
<br>> Hi all!!!<br>><br>> I'm experiencing quite difficulties setting up a dedicated (and separated)<br>> presence server with NATted end-points and the dstblacklist feature.<br>><br>> I'd like to get some info about the construction of the most important
<br>> headers (Req-URI,Contact,To,From,Via,Routr) for the different NOTIFY<br>> modalities depending on the state of the subscription.<br>><br>> Setting up async_auth_queries I've seen the pending and the active NOTIFY
<br>> have different Req-URI and the second one is blocked by the NAT router.<br>> Further mid-dialog NOTIFYs providing changes in the presence status has also<br>> different headers...<br>> My main concern is whether the info for constructing the routing headers is
<br>> taken from location table, from watcherinfo.dialog table, or from the<br>> incoming message...I know I could follow the code but an explanation would<br>> provide a really helpfull overview and later checking the code will be much
<br>> simpler.<br>><br>><br>> Thanks in advance,<br>> Samuel.<br><br>> _______________________________________________<br>> Serusers mailing list<br>> <a href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org
</a><br>> <a href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a><br><br></blockquote></div><br>