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.
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
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@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.
VaclavOn Č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
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@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@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.
VaclavOn Č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
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@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@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.
VaclavOn Č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
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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...
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??
Regards,
Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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.
VaclavOn Č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
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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.)
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...
Vaclav
Regards,
Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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.
VaclavOn Č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
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
2007/8/6, Vaclav Kubart vaclav.kubart@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.
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.
Vaclav
Regards,
Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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.
VaclavOn Č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
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Po, srp 06, 2007 at 12:20:09 +0200, samuel wrote:
2007/8/6, Vaclav Kubart vaclav.kubart@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... ;-)
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...
with regards, Vaclav
Regards,
Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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 > >
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
2007/8/6, Vaclav Kubart vaclav.kubart@iptel.org:
On Po, srp 06, 2007 at 12:20:09 +0200, samuel wrote:
2007/8/6, Vaclav Kubart vaclav.kubart@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,
VaclavRegards,
Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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 > > > > >
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
You can actually use the select and avps to implement Path header functionality in ser.cfg by storing path info in db. I have never done it, but a how-to for iptel.org faqs would be much appreciated ;-) g-)
Vaclav Kubart wrote:
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.)
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...
Vaclav
Regards,
Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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.
VaclavOn Č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 >
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Presence stuff uses tm callbacks to send messages and does not follow the config file (that's what Vaclav was saying) and it's therefore impossible to use this approach for presence. Moreover, I would definetely prefer integrating Path and Service-Route in the SER core and not in the routing script....
samuel.
2007/8/15, Greger V. Teigre greger@teigre.com:
You can actually use the select and avps to implement Path header functionality in ser.cfg by storing path info in db. I have never done it, but a how-to for iptel.org faqs would be much appreciated ;-) g-)
Vaclav Kubart wrote:
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.)
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...
Vaclav
Regards,
Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@iptel.org vaclav.kubart@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.
VaclavOn 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@gmail.com samu60@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@iptel.org 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.
VaclavOn Č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.orghttp://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________Serusers mailing list Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________Serusers mailing list Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
Hi Samuel, Of course, I didn't think about the presence send stuff :-) Yes, I agree, path should be in SER (not core, but a module). And it should be fairly simple to implement, it's just that nobody has stepped up and offered to do it... So, if you feel like picking up the old path module made by Andreas and make a shot at it, feel fre :-) I believe Jan has some input on how to do it, so you can post a suggestion for how to implement to serdev. g-)
samuel wrote:
Presence stuff uses tm callbacks to send messages and does not follow the config file (that's what Vaclav was saying) and it's therefore impossible to use this approach for presence. Moreover, I would definetely prefer integrating Path and Service-Route in the SER core and not in the routing script....
samuel.
2007/8/15, Greger V. Teigre <greger@teigre.com mailto:greger@teigre.com>:
You can actually use the select and avps to implement Path header functionality in ser.cfg by storing path info in db. I have never done it, but a how-to for iptel.org <http://iptel.org> faqs would be much appreciated ;-) g-) Vaclav Kubart wrote: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.)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... VaclavRegards, Samuel. 2007/8/6, Vaclav Kubart <vaclav.kubart@iptel.org> <mailto:vaclav.kubart@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 happenedwitha separated prosence proxy... I was wondering...In the case of a single SIP server (proxy,registrar,presence,...) when the "presence" part sends the NOTIFYtoa natted UA and this latter one replies with the 200OK, the Contactwouldcontain the internal IP and since this NOTIFY is not handled by the SER route config file , it can not be managed by nathelper|mediaproxyoptions.This would cause a modification in the target of the dialog to theinternalIP (following RFC 3261) and the presence dialog would be useless becausenonotifications would work....am I right? Thanks, Samuel. 2007/8/3, samuel <samu60@gmail.com> <mailto:samu60@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@iptel.org> <mailto: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 >> mailto:Serusers@lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers_______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers_______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Just reporting...
That's the parameter I needed. I set notify_is_refresh to 0 and everything seems to work through NAT.
Thanks, Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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.
VaclavOn Č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
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
:-) Yes, it seems to be working but it is hidden bug because NOTIFY *is* target refresh request. Vaclav
On Út, srp 07, 2007 at 09:33:12 +0200, samuel wrote:
Just reporting...
That's the parameter I needed. I set notify_is_refresh to 0 and everything seems to work through NAT.
Thanks, Samuel.
2007/8/6, Vaclav Kubart vaclav.kubart@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.
VaclavOn 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@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@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.
VaclavOn Č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
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Greger V. Teigre -
samuel -
Vaclav Kubart