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

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: with to would options. internal no to loose SUBSCRIBE feature. important NOTIFY status the explanation will be

On Po, srp 06, 2007 at 11:41:46 +0200, samuel wrote: "easily" a process bit Good idea. :-) I like it much more than calling script routes from presence modules. And it is much easier to implement it. But similar effect could be probably got by forwarding the SUBSCRIBE request once more to itself if it will be needed to process the NOTIFYs by nathelper. (Adds a step to routes where can be the "deNATification" done.)

in Sorry, we don't support these in presence modules...

that in happened NOTIFY SER because a Req-URI. NOTIFY results. URI only request (and active NAT routing from

On Po, srp 06, 2007 at 12:20:09 +0200, samuel wrote: the little NOTIFYs :P.... necessary. Calling script routes from modules seems less transparent than this... ;-)

compatibility routing use :-)) I'm not sure if it helps...

Vaclav say, won't was and the Contact the nathelper|mediaproxy the the with ago. sending request (if is sent dstblacklist most different the the presence or code

You can actually use the select and avps to implement Path header functionality in ser.cfg by storing path info in db. I have never done it, but a how-to for iptel.org faqs would be much appreciated ;-) g-) Vaclav Kubart wrote: On Po, srp 06, 2007 at 11:41:46 +0200, samuel wrote: 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... Good idea. :-) I like it much more than calling script routes from presence modules. And it is much easier to implement it. But similar effect could be probably got by forwarding the SUBSCRIBE request once more to itself if it will be needed to process the NOTIFYs by nathelper. (Adds a step to routes where can be the "deNATification" done.) 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?? Sorry, we don't support these in presence modules... Vaclav Regards, Samuel. 2007/8/6, Vaclav Kubart <vaclav.kubart(a)iptel.org> <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> <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> <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@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers

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: with to would options. internal no to loose SUBSCRIBE feature. important NOTIFY status the explanation will be