I'll give a try to this parameter...I didn't pay enough attention to the serdev mail....<br><br>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...
<br><br>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.0 release and select framework??<br><br>Regards,<br><br>Samuel.<br><br><div><span class="gmail_quote">2007/8/6, 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;">
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>> mmmm<br>><br>> coming back to the discussion....the missing OK Contact mangle happened with<br>> 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 to
<br>> a natted UA and this latter one replies with the 200OK, the Contact would<br>> 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 options.
<br>> This would cause a modification in the target of the dialog to the internal<br>> IP (following RFC 3261) and the presence dialog would be useless because no<br>> notifications would work....am I right?<br>>
<br>> Thanks,<br>> Samuel.<br>><br>> 2007/8/3, samuel <<a href="mailto:samu60@gmail.com">samu60@gmail.com</a>>:<br>> ><br>> > 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">vaclav.kubart@iptel.org</a>>:<br>> > ><br>> > > 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<br>> > > 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>> > ><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<br>> > > NOTIFY<br>> > > > have different Req-URI and the second one is blocked by the NAT
<br>> > > router.<br>> > > > Further mid-dialog NOTIFYs providing changes in the presence status<br>> > > has also<br>> > > > different headers...<br>> > > > My main concern is whether the info for constructing the routing
<br>> > > 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<br>> > > would
<br>> > > > provide a really helpfull overview and later checking the code will be<br>> > > 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>> > ><br>> ><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>