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

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...

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??

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