6 Aug
2007
6 Aug
'07
12:41 p.m.
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