mmmm<br><br>coming back to the discussion....the missing OK Contact mangle happened with a separated prosence proxy...<br><br>I was wondering...In the case of a single SIP server (proxy,registrar,presence,...) when the "presence" part sends the NOTIFY to a natted UA and this latter one replies with the 200OK, the Contact would contain the internal IP and since this NOTIFY is not handled by the SER route config file , it can not be managed by nathelper|mediaproxy options. This would cause a modification in the target of the dialog to the internal IP (following RFC 3261) and the presence dialog would be useless because no notifications would work....am I right?
<br><br>Thanks,<br>Samuel.<br><br><div><span class="gmail_quote">2007/8/3, samuel <<a href="mailto:samu60@gmail.com">samu60@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
vaclav.kubart@iptel.org</a>>:</span><div><span class="e" id="q_1142aeee8ff4d588_1"><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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Serusers@lists.iptel.org
</a><br>> <a href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.iptel.org/mailman/listinfo/serusers</a><br><br></blockquote></span>
</div></div><br>
</blockquote></div><br>