2007/8/2, Vaclav Kubart <vaclav.kubart@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@lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers