Re: [Serusers] NOTIFY header construction for mid-dialog presence event package

2007/8/6, Vaclav Kubart <vaclav.kubart(a)iptel.org>rg>: This will only complicate routing script beyond human understanding :P.... I don't like the looback-routing algorithms unless it's more than necessary.

I know ;) It was more a wish for TM module to support these headers.....kind of use case for enforce its inclusion in further release roadmap.

> > > > > Regards, > > > > Samuel. > > > > 2007/8/6, Vaclav Kubart <vaclav.kubart(a)iptel.org>rg>: > > > > > > 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: > > > > mmmm > > > > > > > > coming back to the discussion....the missing OK Contact mangle > happened > > > with > > > > 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 > > > to > > > > a natted UA and this latter one replies with the 200OK, the Contact > > > would > > > > 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 > > > options. > > > > This would cause a modification in the target of the dialog to the > > > internal > > > > IP (following RFC 3261) and the presence dialog would be useless > because > > > no > > > > notifications would work....am I right? > > > > > > > > Thanks, > > > > Samuel. > > > > > > > > 2007/8/3, samuel <samu60(a)gmail.com>om>: > > > > > > > > > > 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 <vaclav.kubart(a)iptel.org>rg>: > > > > > > > > > > > > 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 > > > to > > > > > > 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 > > > loose > > > > > > 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 > > > SUBSCRIBE > > > > > > request as RFC says. > > > > > > > > > > > > Vaclav > > > > > > > > > > > > On Čt, srp 02, 2007 at 12:05:02 +0200, samuel wrote: > > > > > > > Hi all!!! > > > > > > > > > > > > > > I'm experiencing quite difficulties setting up a dedicated > (and > > > > > > separated) > > > > > > > presence server with NATted end-points and the dstblacklist > > > feature. > > > > > > > > > > > > > > I'd like to get some info about the construction of the most > > > important > > > > > > > > > > > > > headers (Req-URI,Contact,To,From,Via,Routr) for the different > > > NOTIFY > > > > > > > modalities depending on the state of the subscription. > > > > > > > > > > > > > > Setting up async_auth_queries I've seen the pending and the > active > > > > > > NOTIFY > > > > > > > have different Req-URI and the second one is blocked by the > NAT > > > > > > router. > > > > > > > Further mid-dialog NOTIFYs providing changes in the presence > > > status > > > > > > has also > > > > > > > different headers... > > > > > > > My main concern is whether the info for constructing the > routing > > > > > > headers is > > > > > > > taken from location table, from watcherinfo.dialog table, or > from > > > the > > > > > > > incoming message...I know I could follow the code but an > > > explanation > > > > > > would > > > > > > > provide a really helpfull overview and later checking the code > > > will be > > > > > > much > > > > > > > simpler. > > > > > > > > > > > > > > > > > > > > > Thanks in advance, > > > > > > > Samuel. > > > > > > > > > > > > > _______________________________________________ > > > > > > > Serusers mailing list > > > > > > > Serusers(a)lists.iptel.org > > > > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > Serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > >

_______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers