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

Mon Aug 6 13:25:49 CEST 2007

2007/8/6, Vaclav Kubart <vaclav.kubart at iptel.org>:
>
> On Po, srp 06, 2007 at 12:20:09 +0200, samuel wrote:
> > 2007/8/6, Vaclav Kubart <vaclav.kubart at iptel.org>:
> > >
> > > 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
> :P....
> > I don't like the looback-routing algorithms unless it's more than
> necessary.
> >
>
> Calling script routes from modules seems less transparent than this...
> ;-)

Definetely!!!!!

> >
> > > > 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...
> >
> >
> > 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.
>
> :-)) I'm not sure if it helps...

Then I'll have to attend a course on how tm module internally works to be
able to start thinking about it...

with regards,
>         Vaclav
>
> > >
> > > >
> > > > Regards,
> > > >
> > > > 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
> > >
> > >
>
> > _______________________________________________
> > 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/3cbe5639/attachment.htm>