6 Jul
2009
6 Jul
'09
8:36 p.m.
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
7 Jul
7 Jul
9 p.m.
On Jul 06, 2009 at 19:36, Klaus Darilion <klaus.mailinglists(a)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
8 Jul
8 Jul
11:58 a.m.
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(a)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 
12:19 p.m.
2009/7/8 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
This is not RFC 3261 compliant. "received" MUST be added if the Via
"sent-by" field is a domain/hostname, always.
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?
This is the correct behavior.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:36 p.m.
On Jul 08, 2009 at 10:58, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Thanks!
Just for clarification:
Yes.
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?
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
1 p.m.
Andrei Pelinescu-Onciul schrieb:
On Jul 08, 2009 at 10:58, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
I found the issue - this can be relevant for sr too:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=200215…
regards
klaus
Thanks!
Just for clarification:
Yes.
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?
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.
1:03 p.m.
On Jul 08, 2009 at 12:00, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
[...]
I found the issue - this can be relevant for sr too:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=200215…
That's a bug in the rfc.
Andrei
1:33 p.m.
Andrei Pelinescu-Onciul schrieb:
On Jul 08, 2009 at 12:00, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
[...]
anyway - should sr be standardconform?
I found the issue - this can be relevant for sr
too:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=200215…
That's a bug in the rfc.
5:20 p.m.
2009/7/8 Andrei Pelinescu-Onciul <andrei(a)iptel.org>rg>:
On Jul 08, 2009 at 12:00, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
[...]
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
<ibc(a)aliax.net>
I found the issue - this can be relevant for sr
too:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=200215…
That's a bug in the rfc.
7:05 p.m.
Iñaki Baz Castillo wrote:
2009/7/8 Andrei Pelinescu-Onciul
<andrei(a)iptel.org>rg>:
I think Andrei meant, that there is no logical reason for a MUST
regards
klaus
On Jul 08, 2009 at 12:00, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
[...]
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 found the issue - this can be relevant for sr
too:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=200215…
That's a bug in the rfc.
8:12 p.m.
2009/7/8 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
For sure :)
But I prefer not to question some IETF specs, or I'd never end... XD
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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
5646
days inactive
5648
days old
10 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
Klaus Darilion