<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;">
On Po, srp 06, 2007 at 11:41:46 +0200, samuel wrote:<br>> 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><br>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.)</blockquote><div><br>This will only complicate routing script beyond human understanding :P.... I don't like the looback-routing algorithms unless it's more than necessary.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> 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><br>Sorry, we don't support these in presence modules...
</blockquote><div><br>I know ;)<br>It was more a wish for TM module to support these headers.....kind of use case for enforce its inclusion in further release roadmap.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Vaclav<br><br>><br>> Regards,<br>><br>> Samuel.<br>><br>> 2007/8/6, Vaclav Kubart <<a href="mailto:vaclav.kubart@iptel.org">vaclav.kubart@iptel.org</a>>:<br>> ><br>> > 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
<br>> > 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
<br>> > to<br>> > > a natted UA and this latter one replies with the 200OK, the Contact<br>> > 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
<br>> > options.<br>> > > This would cause a modification in the target of the dialog to the<br>> > internal<br>> > > IP (following RFC 3261) and the presence dialog would be useless because<br>
> > 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<br>> > 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<br>
> > 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<br>> > 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
<br>> > feature.<br>> > > > > ><br>> > > > > > I'd like to get some info about the construction of the most<br>> > important<br>> > > > ><br>> > > > > > headers (Req-URI,Contact,To,From,Via,Routr) for the different
<br>> > 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
<br>> > 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<br>> > the<br>> > > > > > incoming message...I know I could follow the code but an<br>> > explanation
<br>> > > > > would<br>> > > > > > provide a really helpfull overview and later checking the code<br>> > 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>> ><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>