Hi!
Can someone please review the documentation of the dns= and rev_dns= parameter? http://sip-router.org/wiki/cookbooks/core-cookbook/devel#dns
They are more or less the same, and the described behavior has IMO nothing to do with the Via's received parameter.
Please also describe dns_cache_del_nonexp
thanks klaus
On Jul 06, 2009 at 19:36, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
Can someone please review the documentation of the dns= and rev_dns= parameter? http://sip-router.org/wiki/cookbooks/core-cookbook/devel#dns
They are more or less the same, and the described behavior has IMO nothing to do with the Via's received parameter.
Please also describe dns_cache_del_nonexp
Done, thanks!
Andrei
Thanks!
Just for clarification:
dns
This parameter controls if the SIP server will try doing a DNS lookup on the address in the Via header of a received sip request to decide if adding a received=<src_ip> parameter to the Via is necessary. Note that Vias containing DNS names (instead of IPs) should have received= added, so turning dns to yes is not recommended.
Default is no.
Does this mean that, if the Via header in the received message contains a domain and:
dns=yes, a lookup is done, and if the domain resolves to the src_ip, then the "received" parameter is not added, but only added when the domain resolves to a different IP address?
dns=no: the "received" parameter is always added?
What about the behavior when the Via header contains an IP address (does this parameter affects the behavior)? Is the "received" parameter always added, or only if it Via-IP differs from source-IP? What about existing "received" parameter - will they be deleted/overwritten.
I ask because some time ago we had problems in Kamailio.
regards klaus
Andrei Pelinescu-Onciul schrieb:
On Jul 06, 2009 at 19:36, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
Can someone please review the documentation of the dns= and rev_dns= parameter? http://sip-router.org/wiki/cookbooks/core-cookbook/devel#dns
They are more or less the same, and the described behavior has IMO nothing to do with the Via's received parameter.
Please also describe dns_cache_del_nonexp
Done, thanks!
Andrei
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
This parameter controls if the SIP server will try doing a DNS lookup on the address in the Via header of a received sip request to decide if adding a received=<src_ip> parameter to the Via is necessary. Note that Vias containing DNS names (instead of IPs) should have received= added, so turning dns to yes is not recommended.
Default is no.
Does this mean that, if the Via header in the received message contains a domain and:
dns=yes, a lookup is done, and if the domain resolves to the src_ip, then the "received" parameter is not added, but only added when the domain resolves to a different IP address?
This is not RFC 3261 compliant. "received" MUST be added if the Via "sent-by" field is a domain/hostname, always.
dns=no: the "received" parameter is always added?
This is the correct behavior.
On Jul 08, 2009 at 10:58, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Thanks!
Just for clarification:
dns
This parameter controls if the SIP server will try doing a DNS lookup on the address in the Via header of a received sip request to decide if adding a received=<src_ip> parameter to the Via is necessary. Note that Vias containing DNS names (instead of IPs) should have received= added, so turning dns to yes is not recommended.
Default is no.
Does this mean that, if the Via header in the received message contains a domain and:
dns=yes, a lookup is done, and if the domain resolves to the src_ip, then the "received" parameter is not added, but only added when the domain resolves to a different IP address?
Yes.
dns=no: the "received" parameter is always added?
Yes, if the address in Via is a DNS name and not an IP (and this is the recommended behaviour according to the rfc).
What about the behavior when the Via header contains an IP address (does this parameter affects the behavior)? Is the "received" parameter always added, or only if it Via-IP differs from source-IP? What about existing "received" parameter - will they be deleted/overwritten.
If the Via contains an IP, received is only added if the Via-IP!=src_IP.
I ask because some time ago we had problems in Kamailio.
I think they do exactly the same thing in kamailio. These config params. are very old, from the early days of ser and I doubt anyone touched them. BTW: they can be turned on from the command line (-r and -R).
Andrei
Andrei Pelinescu-Onciul schrieb:
On Jul 08, 2009 at 10:58, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Thanks!
Just for clarification:
dns
This parameter controls if the SIP server will try doing a DNS lookup on the address in the Via header of a received sip request to decide if adding a received=<src_ip> parameter to the Via is necessary. Note that Vias containing DNS names (instead of IPs) should have received= added, so turning dns to yes is not recommended.
Default is no.
Does this mean that, if the Via header in the received message contains a domain and:
dns=yes, a lookup is done, and if the domain resolves to the src_ip, then the "received" parameter is not added, but only added when the domain resolves to a different IP address?
Yes.
dns=no: the "received" parameter is always added?
Yes, if the address in Via is a DNS name and not an IP (and this is the recommended behaviour according to the rfc).
What about the behavior when the Via header contains an IP address (does this parameter affects the behavior)? Is the "received" parameter always added, or only if it Via-IP differs from source-IP? What about existing "received" parameter - will they be deleted/overwritten.
If the Via contains an IP, received is only added if the Via-IP!=src_IP.
I ask because some time ago we had problems in Kamailio.
I think they do exactly the same thing in kamailio. These config params. are very old, from the early days of ser and I doubt anyone touched them.
I found the issue - this can be relevant for sr too: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2002156...
regards klaus
On Jul 08, 2009 at 12:00, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...]
I found the issue - this can be relevant for sr too: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2002156...
That's a bug in the rfc.
Andrei
Andrei Pelinescu-Onciul schrieb:
On Jul 08, 2009 at 12:00, Klaus Darilion klaus.mailinglists@pernau.at wrote: [...]
I found the issue - this can be relevant for sr too: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2002156...
That's a bug in the rfc.
anyway - should sr be standardconform?
2009/7/8 Andrei Pelinescu-Onciul andrei@iptel.org:
On Jul 08, 2009 at 12:00, Klaus Darilion klaus.mailinglists@pernau.at wrote:
[...]
I found the issue - this can be relevant for sr too: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2002156...
That's a bug in the rfc.
Why? I reported that bug and my conclusion was: After getting replies from different sources I confirm that this is an issue in OpenSer. A RFC3581 compliant device MUST add "received" parameter (even if not necessary) in case it handles "rport" parameter in a request/response.
It's "clearly" defined in RFC 3581, I don't see the bug in the RFC at all.
Iñaki Baz Castillo wrote:
2009/7/8 Andrei Pelinescu-Onciul andrei@iptel.org:
On Jul 08, 2009 at 12:00, Klaus Darilion klaus.mailinglists@pernau.at wrote: [...]
I found the issue - this can be relevant for sr too: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2002156...
That's a bug in the rfc.
Why? I reported that bug and my conclusion was: After getting replies from different sources I confirm that this is an issue in OpenSer. A RFC3581 compliant device MUST add "received" parameter (even if not necessary) in case it handles "rport" parameter in a request/response.
It's "clearly" defined in RFC 3581, I don't see the bug in the RFC at all.
I think Andrei meant, that there is no logical reason for a MUST
regards klaus
2009/7/8 Klaus Darilion klaus.mailinglists@pernau.at:
It's "clearly" defined in RFC 3581, I don't see the bug in the RFC at all.
I think Andrei meant, that there is no logical reason for a MUST
For sure :) But I prefer not to question some IETF specs, or I'd never end... XD
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
Klaus Darilion