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

[Vaclav Kubart]

:-) Yes, it seems to be working but it is hidden bug because NOTIFY *is*
target refresh request.
	Vaclav

On Út, srp 07, 2007 at 09:33:12 +0200, samuel wrote:
> Just reporting...
> 
> That's the parameter I needed. I set notify_is_refresh to 0 and everything
> seems to work through NAT.
> 
> Thanks,
> Samuel.
> 
> 2007/8/6, Vaclav Kubart <vaclav.kubart at iptel.org>:
> >
> > 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 at gmail.com>:
> > > >
> > > > 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 at iptel.org>:
> > > > >
> > > > > 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 at lists.iptel.org
> > > > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > > >
> > > > >
> > > >
> >
> > > _______________________________________________
> > > Serusers mailing list
> > > Serusers at lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >

> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers