Hi Klaus,
Here are the packets. The ngrep of the DNS lookup does not show much. I
can only see the client IP (in reverse order).
client: 213.5.17.236
Openser: 213.5.43.134, 213.5.8.5
DNS: 213.5.41.8
thank you
U 2006/12/14 12:00:09.612841 213.5.17.236:5060 -> 213.5.43.134:5060
INVITE sip:2116872933@i-call.gr;user=phone SIP/2.0.
Via: SIP/2.0/UDP 213.5.17.236:5060;branch=z9hG4bK-nykmi2fjal1m;rport.
From: "George Papadopoulos" <sip:geop@i-call.gr>;tag=pt3u7ggbqm.
To: <sip:2116872933@i-call.gr;user=phone>.
Call-ID: 3c28be1c1adb-0vv5406jgtfv@213-5-17-236.
CSeq: 2 INVITE.
Max-Forwards: 70.
Contact: <sip:geop@213.5.17.236:5060;line=9yt55o5b>.
P-Key-Flags: keys="3".
User-Agent: snom190-3.56w.
Accept-Language: en.
Accept: application/sdp.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO.
Allow-Events: talk, hold, refer.
Supported: timer, 100rel, replaces.
Session-Expires: 3600.
Content-Type: application/sdp.
Content-Length: 268.
.
v=0.
o=root 886017132 886017132 IN IP4 213.5.17.236.
s=call.
c=IN IP4 213.5.17.236.
t=0 0.
m=audio 10190 RTP/AVP 0 8 18 101.
a=rtpmap:0 pcmu/8000.
a=rtpmap:8 pcma/8000.
a=rtpmap:18 g729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=sendrecv.
#
U 2006/12/14 12:00:09.614000 213.5.8.5:50120 -> 213.5.41.8:53
.............236.17.5.213.in-addr.arpa.....
#
U 2006/12/14 12:00:09.618660 213.5.41.8:53 -> 213.5.8.5:50120
.............236.17.5.213.in-addr.arpa.............*0.7.ns0.altectelecom
s.gr.
hostmaster.;w.e...p.... ..:...Q.
#
U 2006/12/14 12:00:09.619325 213.5.43.134:5060 -> 213.5.17.236:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP
213.5.17.236:5060;branch=z9hG4bK-nykmi2fjal1m;rport=5060.
From: "George Papadopoulos" <sip:geop@i-call.gr>;tag=pt3u7ggbqm.
To: <sip:2116872933@i-call.gr;user=phone>.
Call-ID: 3c28be1c1adb-0vv5406jgtfv@213-5-17-236.
CSeq: 2 INVITE.
Server: OpenSer (1.1.0-notls (x86_64/linux)).
Content-Length: 0.
.
-----Original Message-----
From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at]
Sent: Friday, December 15, 2006 12:42 PM
To: Papadopoulos Georgios
Cc: Bogdan-Andrei Iancu; users(a)openser.org
Subject: Re: [Users] DNS queries and TLS
Can you also post the INVITE which is processd and the ngrep
of the DNS lookup (which domain is lookup up)
regards
klaus
Papadopoulos Georgios wrote:
Hi Bogdan,
I am not using any nat test functions, at least at the part of the
script that handles INVITEs. I am using allow_trusted() in
caching mode.
But if allow_trusted was doing the DNS query then
I should
also see it
after the first INVITE and before the "407
Proxy Auth
Reqd". I am also
using lcr module. So, is it possible that
load_gws() or
next_gw() is
responsible for the DNS query?
Regards,
George
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
> Sent: Thursday, December 14, 2006 7:14 PM
> To: Papadopoulos Georgios
> Cc: users(a)openser.org
> Subject: Re: [Users] DNS queries and TLS
>
> Hi George,
>
>
> TLS = Thread Local Storage
>
>
>
> Papadopoulos Georgios wrote:
>
>> Hello,
>>
>> I am having some performance issues with Openser and I tend
> to believe
>> they are related with DNS. So I am trying to figure out
> when and why
>> Openser is doing DNS queries. Doing ngrep on port 53 I
> realized that
>> right before sending out the "100 trying -- your call is
> important to
>> us" message, Openser is doing a reverse DNS lookup for
the IP where
>> the INVITE came from. So the sequence is
something like:
>> client Openser DNS
>> |---INVITE------------------------>|
>> |<---407 Proxy Auth Reqd---|
>> |---ACK--------------------------->|
>> |---INVITE------------------------>|
>> |---client
IP?-------->|
>>
> |<-------------------------|
>> |<--------------------100 trying---|
>>
>>
>> I am using Openser-1.1.0-notls and in my script I have dns=no
>> rev_dns=no So first question is whether this DNS query is
necessary
>> and how I could avoid it.
> the configuration options are ok (as time you do not use
the command
> line -r or -R). I would say the rev dns query
is not
triggered by the
> t_relay() (actually the params control what
DNS queries should be
> done when testing the "received" VIA param) - I have
tested and I
see
> no query before 100 trying, so it should be
ok.
>
> maybe you are using some nat test functions (like
> client_nat_test) or any other script functions that mask a dns
> query...can you check on this?
>
>>
>> What is furthermore confusing is that I have a test
system with the
>> same Openser version and same script,
where this DNS query is not
>> happening. Looking into the production system I found the
following:
>> ser2:/usr/local/openser-1.1.0-notls/sbin#
ldd openser
>> linux-gate.so.1 => (0xffffe000)
>> libdl.so.2 => /lib/tls/libdl.so.2 (0x55571000)
>> libresolv.so.2 => /lib/tls/libresolv.so.2 (0x55574000)
>> libc.so.6 => /lib/tls/libc.so.6 (0x55587000)
>> /lib/ld-linux.so.2 => /lib/ld-linux.so.2
> (0x55555000) whereas
>> the test system shows:
>> sertest:/usr/local/openser-1.1.0-notls/sbin# ldd openser
>> libdl.so.2 => /lib/libdl.so.2 (0x7002c000)
>> libresolv.so.2 => /lib/libresolv.so.2 (0x70040000)
>> libc.so.6 => /lib/libc.so.6 (0x70064000)
>> /lib/ld-linux.so.2 (0x70000000) So the two
systems link to
>> different libresolv.so libraries. Is the
tls/libresolve.so that is
>> responsible for the DNS query? Given that
in both cases I
> am using the
>> notls version of Openser 1.1, why is there a difference
between the
>> two?
> the "tls" frm /lib/tls comes from "Thread Local Storage" and
there
> are libraries implementations for thread env. It has nothing to do
> with TLS (Transport Layer Security)
>
> regards,
> bogdan
>
>>
>> thank you for any help
>>
>> George
>>
>>
>>
>> Disclaimer
>>
>> The information in this e-mail and any attachments is
> confidential. It
>> is intended solely for the attention and use of the named
>> addressee(s). If you are not the intended recipient, or person
>> responsible for delivering this information to the intended
> recipient,
>> please notify the sender immediately. Unless you are the intended
>> recipient or his/her representative you are not
authorized to, and
>> must not, read, copy, distribute, use or
retain this
message or any
part of it. E-mail transmission cannot be guaranteed
to be
secure or
error-free as information could be intercepted,
corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses.
-------------------------------------------------------------
----------
-
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
Klaus Darilion
nic.at