6 Aug
2007
6 Aug
'07
1:20 p.m.
2007/8/6, Vaclav Kubart <vaclav.kubart(a)iptel.org>rg>:
I know ;)
It was more a wish for TM module to support these headers.....kind of use
case for enforce its inclusion in further release roadmap.
Vaclav
On Po, srp 06, 2007 at 11:41:46 +0200, samuel wrote:
This will only complicate routing script beyond human understanding :P....
I don't like the looback-routing algorithms unless it's more than necessary.
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...
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