6 Aug
2007
6 Aug
'07
11:24 a.m.
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