<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;">
On Po, srp 06, 2007 at 12:20:09 +0200, samuel wrote:<br>> 2007/8/6, Vaclav Kubart <<a href="mailto:vaclav.kubart@iptel.org">vaclav.kubart@iptel.org</a>>:<br>> ><br>> > 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<br>> > "easily" a<br>> > > separate presence proxy or route the messages to yourself so you can<br>> > process
<br>> > > it again in your config script. This would, however, break just a little<br>> > 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
<br>> > 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>><br>> This will only complicate routing script beyond human understanding :P....<br>> I don't like the looback-routing algorithms unless it's more than necessary.
<br>><br><br>Calling script routes from modules seems less transparent than this...<br>;-)</blockquote><div><br>Definetely!!!!! <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<br>> > 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...<br>><br>><br>> I know ;)<br>> It was more a wish for TM module to support these headers.....kind of use
<br>> case for enforce its inclusion in further release roadmap.<br><br>:-)) I'm not sure if it helps...</blockquote><div><br>Then I'll have to attend a course on how tm module internally works to be able to start thinking about it...
<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;">with regards,<br> Vaclav<br><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,<br>> > 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<br>> > 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
<br>> > 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<br>> > 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<br>> > 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
<br>> > 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<br>> > a<br>> > > > > > non-routable IP. That's why further messages had the wronf<br>> > 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<br>> > NOTIFY<br>> > > > to<br>> > > > > > > allow its modifications, but I had not enough time to get
<br>> > results.<br>> > > > > > ><br>> > > > > > > The NOTIFY should be constructed according RFC 3261; the request<br>> > URI<br>> > > > > > > should be the value from Contact of the SUBSCRIBE request (if
<br>> > 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<br>> > 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<br>> > (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<br>> > active<br>> > > > > > > NOTIFY<br>> > > > > > > > have different Req-URI and the second one is blocked by the
<br>> > 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<br>> > routing<br>> > > > > > > headers is
<br>> > > > > > > > taken from location table, from watcherinfo.dialog table, or<br>> > 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>> ><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>