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

[samuel]

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070806/59251dd5/attachment.htm>