6 Aug
2007
6 Aug
'07
2:25 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
Then I'll have to attend a course on how tm module internally works to be
able to start thinking about it...
with regards,
On Po, srp 06, 2007 at 12:20:09 +0200, samuel wrote:
:P....
Calling script routes from modules seems less transparent than this...
;-)
Definetely!!!!!
2007/8/6, Vaclav Kubart
<vaclav.kubart(a)iptel.org>rg>:
> 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.)
This will only complicate routing script beyond human understanding I don't like the looback-routing algorithms
unless it's more than
necessary.
> > 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... case for enforce its inclusion in further release
roadmap.
:-)) I'm not sure if it helps... Vaclav
>
> >
> > 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
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers