Presence stuff uses tm callbacks to send messages and does not follow the config file (that's what Vaclav was saying) and it's therefore impossible to use this approach for presence.<br>Moreover, I would definetely prefer integrating Path and Service-Route in the SER core and not in the routing script....
<br><br>samuel.<br><br><div><span class="gmail_quote">2007/8/15, Greger V. Teigre <<a href="mailto:greger@teigre.com">greger@teigre.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;">
<div bgcolor="#ffffff" text="#000000">
You can actually use the select and avps to implement Path header
functionality in ser.cfg by storing path info in db. I have never done
it, but a how-to for <a href="http://iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">iptel.org</a> faqs would be much appreciated ;-)<br><span class="sg">
g-)</span><div><span class="e" id="q_1146940f2d8a0d5e_2"><br>
<br>
Vaclav Kubart wrote:
<blockquote type="cite">
<pre>On Po, srp 06, 2007 at 11:41:46 +0200, samuel wrote:<br> </pre>
<blockquote type="cite">
<pre>I'll give a try to this parameter...I didn't pay enough attention to the<br>serdev mail....<br><br>Maybe a reasonable approach would be to be able to define a presence<br>outbound proxy (as it's done in presence_b2b) and you can set up "easily" a
<br>separate presence proxy or route the messages to yourself so you can process<br>it again in your config script. This would, however, break just a little bit<br>3261 routing algorithm....easy but I don't like it...
<br> </pre>
</blockquote>
<pre>Good idea. :-) I like it much more than calling script routes from presence<br>modules. And it is much easier to implement it.<br><br>But similar effect could be probably got by forwarding the SUBSCRIBE<br>request once more to itself if it will be needed to process the NOTIFYs
<br>by nathelper. (Adds a step to routes where can be the "deNATification"<br>done.)<br><br> </pre>
<blockquote type="cite">
<pre>Thinking loud...what about Path or Service-Route headers compatibility in<br>presence modules?? Setting up these headers would allow flexible routing<br>while keeping compliancy to standards...Can this be achieved with
<br>2.0release and select framework??<br> </pre>
</blockquote>
<pre>Sorry, we don't support these in presence modules...<br><br>        Vaclav<br><br> </pre>
<blockquote type="cite">
<pre>Regards,<br><br>Samuel.<br><br>2007/8/6, Vaclav Kubart <a href="mailto:vaclav.kubart@iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"><vaclav.kubart@iptel.org></a>:<br>
</pre>
<blockquote type="cite">
<pre>Yes, you are right.<br><br>But Maxim has introduced new module parameter by which you can say, that<br>NOTIFY is not target refresh request and thus NOTIFY responses won't<br>refresh the target.<br><br>From my point of view is this only temporary hack (because NOTIFY was in
<br>some discussions aggreed to be target refresh). Better solution is<br>probably to let the NOTIFY go through config script and process it and<br>its responses by nathelper.<br><br> Vaclav<br><br>On Po, srp 06, 2007 at 10:24:17 +0200, samuel wrote:
<br> </pre>
<blockquote type="cite">
<pre>mmmm<br><br>coming back to the discussion....the missing OK Contact mangle happened<br> </pre>
</blockquote>
<pre>with<br> </pre>
<blockquote type="cite">
<pre>a separated prosence proxy...<br><br>I was wondering...In the case of a single SIP server<br>(proxy,registrar,presence,...) when the "presence" part sends the NOTIFY<br> </pre>
</blockquote>
<pre>to<br> </pre>
<blockquote type="cite">
<pre>a natted UA and this latter one replies with the 200OK, the Contact<br> </pre>
</blockquote>
<pre>would<br> </pre>
<blockquote type="cite">
<pre>contain the internal IP and since this NOTIFY is not handled by the SER<br>route config file , it can not be managed by nathelper|mediaproxy<br> </pre>
</blockquote>
<pre>options.<br> </pre>
<blockquote type="cite">
<pre>This would cause a modification in the target of the dialog to the<br> </pre>
</blockquote>
<pre>internal<br> </pre>
<blockquote type="cite">
<pre>IP (following RFC 3261) and the presence dialog would be useless because<br> </pre>
</blockquote>
<pre>no<br> </pre>
<blockquote type="cite">
<pre>notifications would work....am I right?<br><br>Thanks,<br>Samuel.<br><br>2007/8/3, samuel <a href="mailto:samu60@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"><samu60@gmail.com>
</a>:<br> </pre>
<blockquote type="cite">
<pre>Ok.<br><br>I found out the "problem", there was a missing NAT handling of the<br>responses, and the 200 OK response updated the target dialog with a<br>non-routable IP. That's why further messages had the wronf Req-URI.
<br><br>Thanks for your pointers,<br>sam.<br><br>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>:
<br> </pre>
<blockquote type="cite">
<pre>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<br> </pre>
</blockquote>
</blockquote>
</blockquote>
<pre>to<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>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
<br> </pre>
</blockquote>
</blockquote>
</blockquote>
<pre>loose<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>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<br>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>SUBSCRIBE<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>request as RFC says.<br><br> Vaclav<br><br>On Čt, srp 02, 2007 at 12:05:02 +0200, samuel wrote:<br> </pre>
<blockquote type="cite">
<pre>Hi all!!!<br><br>I'm experiencing quite difficulties setting up a dedicated (and<br> </pre>
</blockquote>
<pre>separated)<br> </pre>
<blockquote type="cite">
<pre>presence server with NATted end-points and the dstblacklist<br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>feature.<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>I'd like to get some info about the construction of the most<br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>important<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>headers (Req-URI,Contact,To,From,Via,Routr) for the different<br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>NOTIFY<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>modalities depending on the state of the subscription.<br><br>Setting up async_auth_queries I've seen the pending and the active<br> </pre>
</blockquote>
<pre>NOTIFY<br> </pre>
<blockquote type="cite">
<pre>have different Req-URI and the second one is blocked by the NAT<br> </pre>
</blockquote>
<pre>router.<br> </pre>
<blockquote type="cite">
<pre>Further mid-dialog NOTIFYs providing changes in the presence<br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>status<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>has also<br> </pre>
<blockquote type="cite">
<pre>different headers...<br>My main concern is whether the info for constructing the routing<br> </pre>
</blockquote>
<pre>headers is<br> </pre>
<blockquote type="cite">
<pre>taken from location table, from watcherinfo.dialog table, or from<br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>the<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>incoming message...I know I could follow the code but an<br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>explanation<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>would<br> </pre>
<blockquote type="cite">
<pre>provide a really helpfull overview and later checking the code<br> </pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>will be<br> </pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>much<br> </pre>
<blockquote type="cite">
<pre>simpler.<br><br><br>Thanks in advance,<br>Samuel.<br> </pre>
</blockquote>
<blockquote type="cite">
<pre>_______________________________________________<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>
<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>
</pre>
</blockquote>
<pre> </pre>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<pre>_______________________________________________<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>
<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>
</pre>
</blockquote>
<pre> </pre>
</blockquote>
</blockquote>
<pre> </pre>
<blockquote type="cite">
<pre>_______________________________________________<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>
<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>
</pre>
</blockquote>
<pre>_______________________________________________<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>
<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>
</pre>
</blockquote>
</span></div></div>
</blockquote></div><br>