<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Samuel,<br>
Of course, I didn't think about the presence send stuff :-)<br>
Yes, I agree, path should be in SER (not core, but a module). And it
should be fairly simple to implement, it's just that nobody has stepped
up and offered to do it... So, if you feel like picking up the old path
module made by Andreas and make a shot at it, feel fre :-) I believe
Jan has some input on how to do it, so you can post a suggestion for
how to implement to serdev.<br>
g-)<br>
<br>
samuel wrote:
<blockquote
cite="mid:d18bd3a10708160359q75f41f2dp96ec1ff5263cf4b0@mail.gmail.com"
type="cite">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
moz-do-not-send="true" 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 moz-do-not-send="true" 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:
</pre>
<blockquote type="cite">
<pre>I'll give a try to this parameter...I didn't pay enough attention to the
serdev mail....
Maybe a reasonable approach would be to be able to define a presence
outbound proxy (as it's done in presence_b2b) and you can set up "easily" a
separate presence proxy or route the messages to yourself so you can process
it again in your config script. This would, however, break just a little bit
3261 routing algorithm....easy but I don't like it...
</pre>
</blockquote>
<pre>Good idea. :-) I like it much more than calling script routes from presence
modules. And it is much easier to implement it.
But similar effect could be probably got by forwarding the SUBSCRIBE
request once more to itself if it will be needed to process the NOTIFYs
by nathelper. (Adds a step to routes where can be the "deNATification"
done.)
</pre>
<blockquote type="cite">
<pre>Thinking loud...what about Path or Service-Route headers compatibility in
presence modules?? Setting up these headers would allow flexible routing
while keeping compliancy to standards...Can this be achieved with
2.0release and select framework??
</pre>
</blockquote>
<pre>Sorry, we don't support these in presence modules...
Vaclav
</pre>
<blockquote type="cite">
<pre>Regards,
Samuel.
2007/8/6, Vaclav Kubart <a moz-do-not-send="true"
href="mailto:vaclav.kubart@iptel.org" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)"><vaclav.kubart@iptel.org></a>:
</pre>
<blockquote type="cite">
<pre>Yes, you are right.
But Maxim has introduced new module parameter by which you can say, that
NOTIFY is not target refresh request and thus NOTIFY responses won't
refresh the target.
>From my point of view is this only temporary hack (because NOTIFY was in
some discussions aggreed to be target refresh). Better solution is
probably to let the NOTIFY go through config script and process it and
its responses by nathelper.
Vaclav
On Po, srp 06, 2007 at 10:24:17 +0200, samuel wrote:
</pre>
<blockquote type="cite">
<pre>mmmm
coming back to the discussion....the missing OK Contact mangle happened
</pre>
</blockquote>
<pre>with
</pre>
<blockquote type="cite">
<pre>a separated prosence proxy...
I was wondering...In the case of a single SIP server
(proxy,registrar,presence,...) when the "presence" part sends the NOTIFY
</pre>
</blockquote>
<pre>to
</pre>
<blockquote type="cite">
<pre>a natted UA and this latter one replies with the 200OK, the Contact
</pre>
</blockquote>
<pre>would
</pre>
<blockquote type="cite">
<pre>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
</pre>
</blockquote>
<pre>options.
</pre>
<blockquote type="cite">
<pre>This would cause a modification in the target of the dialog to the
</pre>
</blockquote>
<pre>internal
</pre>
<blockquote type="cite">
<pre>IP (following RFC 3261) and the presence dialog would be useless because
</pre>
</blockquote>
<pre>no
</pre>
<blockquote type="cite">
<pre>notifications would work....am I right?
Thanks,
Samuel.
2007/8/3, samuel <a moz-do-not-send="true"
href="mailto:samu60@gmail.com" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)"><samu60@gmail.com>
</a>:
</pre>
<blockquote type="cite">
<pre>Ok.
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.
Thanks for your pointers,
sam.
2007/8/2, Vaclav Kubart <a moz-do-not-send="true"
href="mailto:vaclav.kubart@iptel.org" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)"><vaclav.kubart@iptel.org></a>:
</pre>
<blockquote type="cite">
<pre>Hi Samuel,
Maxim Sobolev was fighting with NAT and presence some time ago.
I was trying to allow calling script route block when sending NOTIFY
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>to
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>allow its modifications, but I had not enough time to get results.
The NOTIFY should be constructed according RFC 3261; the request URI
should be the value from Contact of the SUBSCRIBE request (if only
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>loose
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>routers in routes appear).
To, From, Via and routes should follow RFC 3261 too.
Contact header value is the address at which the SUBSCRIBE request
arrives to the server (according examples in RFC 3856, this is
controversial but possible).
Modifying of async_auth_queries should have no influence on sent
NOTIFYs. If does, it is probably a bug.
All headers you mentioned are derived from dialog initiating
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre>SUBSCRIBE
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>request as RFC says.
Vaclav
On Čt, srp 02, 2007 at 12:05:02 +0200, samuel wrote:
</pre>
<blockquote type="cite">
<pre>Hi all!!!
I'm experiencing quite difficulties setting up a dedicated (and
</pre>
</blockquote>
<pre>separated)
</pre>
<blockquote type="cite">
<pre>presence server with NATted end-points and the dstblacklist
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>feature.
</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
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>important
</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
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>NOTIFY
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>modalities depending on the state of the subscription.
Setting up async_auth_queries I've seen the pending and the active
</pre>
</blockquote>
<pre>NOTIFY
</pre>
<blockquote type="cite">
<pre>have different Req-URI and the second one is blocked by the NAT
</pre>
</blockquote>
<pre>router.
</pre>
<blockquote type="cite">
<pre>Further mid-dialog NOTIFYs providing changes in the presence
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>status
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>has also
</pre>
<blockquote type="cite">
<pre>different headers...
My main concern is whether the info for constructing the routing
</pre>
</blockquote>
<pre>headers is
</pre>
<blockquote type="cite">
<pre>taken from location table, from watcherinfo.dialog table, or from
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>the
</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
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>explanation
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>would
</pre>
<blockquote type="cite">
<pre>provide a really helpfull overview and later checking the code
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre>will be
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre>much
</pre>
<blockquote type="cite">
<pre>simpler.
Thanks in advance,
Samuel.
</pre>
</blockquote>
<blockquote type="cite">
<pre>_______________________________________________
Serusers mailing list
<a moz-do-not-send="true" href="mailto:Serusers@lists.iptel.org"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a moz-do-not-send="true"
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>_______________________________________________
Serusers mailing list
<a moz-do-not-send="true" href="mailto:Serusers@lists.iptel.org"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a moz-do-not-send="true"
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>_______________________________________________
Serusers mailing list
<a moz-do-not-send="true" href="mailto:Serusers@lists.iptel.org"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a moz-do-not-send="true"
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>_______________________________________________
Serusers mailing list
<a moz-do-not-send="true" href="mailto:Serusers@lists.iptel.org"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a moz-do-not-send="true"
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>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Serusers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Serusers@lists.iptel.org">Serusers@lists.iptel.org</a>
<a class="moz-txt-link-freetext" href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a>
</pre>
</blockquote>
</body>
</html>