[Home]

Summary:ASTERISK-11002: Asterisk Realtime not resoving host names
Reporter:Atif Khan (akhan01)Labels:
Date Opened:2007-12-10 10:58:30.000-0600Date Closed:2007-12-14 17:30:49.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/DatabaseSupport
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Using asterisk Realtime I have noticed that incoming calls will not work
unless you change the HOST field from domain name to a physical IP address.

If a domain name is specified for host the bellow NOTICE is seen on asterisk
NOTICE[3008] chan_sip.c: Call from '' to extension '13864345565' rejected because extension not found.

We tested this many times and if a domain name is specified for HOST then 98%
of the incoming calls gets rejects with the above NOTICE.



****** ADDITIONAL INFORMATION ******

Asterisk Version SVN-branch-1.4-r91541
OS : CentOS
Comments:By: Joshua C. Colp (jcolp) 2007-12-10 11:19:55.000-0600

Please provide a sip debug with this.
By: Tilghman Lesher (tilghman) 2007-12-11 09:58:20.000-0600

Also, what are the contents of /etc/resolv.conf ?
By: Atif Khan (akhan01) 2007-12-11 10:07:48.000-0600

resolve.conf
nameserver 4.2.2.2
nameserver 4.2.2.3

Again, there is nothing wrong with the name server.
The server has been purring for almost a year.  The only diff this time
is that we migrated to Asterisk Realtime.

Unless we do not have a physical IP in HOST field it will not work.

Thanks
By: Tilghman Lesher (tilghman) 2007-12-12 11:20:50.000-0600

Okay, so we need that sip debug.
By: Terry Wilson (twilson) 2007-12-12 19:09:06.000-0600

I just tried this with r92614 with realtime (odbc, mysql db), host set as client.test.local with an entry in my /etc/hosts file for it.  asterisk looked it and and completed the call.
By: Atif Khan (akhan01) 2007-12-14 16:32:26.000-0600

Bellow is the debug.
Notice "Found no matching peer or user for '64.34.181.47:5060'"

[Dec 14 16:14:59] VERBOSE[3008] logger.c: Using INVITE request as basis request - 25cf9b160722c5a12f566a3870da13e1@64.34.181.47
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Found no matching peer or user for '64.34.181.47:5060'
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Found RTP audio format 0
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Found RTP audio format 101
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Peer audio RTP is at port 64.34.181.47:15326
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Found audio description format PCMU for ID 0
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Found audio description format telephone-event for ID 101
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Capabilities: us - 0x4 (ulaw), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Peer audio RTP is at port 64.34.181.47:15326
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Looking for 17058124935 in default (domain 75.126.42.12)
[Dec 14 16:14:59] VERBOSE[3008] logger.c:
<--- Reliably Transmitting (NAT) to 64.34.181.47:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 64.34.181.47:5060;branch=z9hG4bK1c911328;received=64.34.181.47;rport=5060
From: "NOT FOUND" <sip:19544939151@64.34.181.47>;tag=as2a8db2da
To: <sip:17058124935@75.126.42.12>;tag=as058e2267
Call-ID: 25cf9b160722c5a12f566a3870da13e1@64.34.181.47
CSeq: 102 INVITE
User-Agent: Timeous PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0


<------------>
[Dec 14 16:14:59] NOTICE[3008] chan_sip.c: Call from '' to extension '17058124935' rejected because extension not found.
[Dec 14 16:14:59] VERBOSE[3008] logger.c: Scheduling destruction of SIP dialog '25cf9b160722c5a12f566a3870da13e1@64.34.181.47' in 32000 ms (Method: INVITE)
[Dec 14 16:14:59] VERBOSE[3008] logger.c:
By: Tilghman Lesher (tilghman) 2007-12-14 17:29:44.000-0600

Okay, so it's fairly obvious why this isn't working for you:  the SIP client isn't sending the hostname; it's sending the IP address, so Asterisk naturally tries to match the IP address in the URI that it sends.

If your client sent the hostname, then you could use the hostname in the realtime database.  However, since it didn't, Asterisk has no way of knowing that that's the host that you wanted.

No, we do not do reverse DNS (PTR lookup) in the middle of a SIP dialog, as that introduces a great deal of latency into the connection.
By: Tilghman Lesher (tilghman) 2007-12-14 17:30:49.000-0600

I'm closing this out as not a bug.  If you change your client to send the hostname, then it will work as you would like it.