[asterisk-users] Calling non-extension numbers issue

[Kayton Sapale]

The two "logs" that I have been able to find are messages on the 
asterisk server in debug. Unfortunately, Nokia does not have any kind of 
logging (sucks).  What I can see is that it is definitely a phone issue, 
just stuck on where to go from here.

First, this if from asterisk in debug
   
    1. -- Registered SIP '104' at 192.168.111.182 port 5060 expires 3600 
-- Saved useragent "E71-2 RM-346 200.21.118" for peer 104 -- Got SIP 
response 400 "Bad Request" back from 192.168.111.182

Second, these are two connection attempts to the same asterisk server, 
one successful, one not:
   
    1. Successful:   Found peer '103'  Found RTP audio format 96  Found 
RTP audio format 0  Found RTP audio format 8  Found RTP audio format 97  
Found RTP audio format 18  Found RTP audio format 98  Found RTP audio 
format 13  Peer audio RTP is at port 192.168.111.183:49152  Found 
unknown media description format AMR for ID 96  Found audio description 
format PCMU for ID 0  Found audio description format PCMA for ID 8  
Found audio description format iLBC for ID 97  Found audio description 
format G729 for ID 18  Found audio description format telephone-event 
for ID 98  Found audio description format CN for ID 13  Capabilities: us 
- 0xe (gsm|ulaw|alaw), peer - audio=0x50c 
(ulaw|alaw|g729|ilbc)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)  
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x3 
(telephone-event|CN), combined - 0x1 (telephone-event)  Peer audio RTP 
is at port 192.168.111.183:49152  Looking for 6789940793 in 
DLPN_Free_Outbound (domain sip.speartek.com)  list_route: hop: 
<sip:103 at 192.168.111.183>

    2. Failure: Found peer '104'  -   message ends at this point

Third, this is from the IIS logs where the same devices connect FROM, 
one successful, one not:

    1. Successful:
          2009-07-01 15:41:10    Local4.Info    192.168.111.1    
%PIX-6-607001: Pre-allocate SIP Signalling UDP secondary channel for 
outside:67.220.106.35/5060 to inside:192.168.111.182 from INVITE message
2009-07-01 15:41:10    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Signalling UDP secondary channel for 
outside:67.220.106.35 to inside:192.168.111.182/5060 from Response 4xx 
message
2009-07-01 15:41:10    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Via UDP secondary channel for outside:67.220.106.35 to 
inside:192.168.111.182/5060 from ACK message
2009-07-01 15:41:10    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Via UDP secondary channel for outside:67.220.106.35 to 
inside:192.168.111.182/5060 from INVITE message
2009-07-01 15:41:10    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Signalling UDP secondary channel for 
outside:67.220.106.35/5060 to inside:192.168.111.182 from INVITE message
2009-07-01 15:41:10    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Signalling UDP secondary channel for 
outside:67.220.106.35 to inside:192.168.111.182/5060 from Response 100 
message
2009-07-01 15:41:10    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Signalling UDP secondary channel for 
outside:67.220.106.35 to inside:192.168.111.182/5060 from Response 180 
message

    2. Failure:
          2009-07-01 15:44:53    Local4.Info    192.168.111.1    
%PIX-6-607001: Pre-allocate SIP Via UDP secondary channel for 
outside:67.220.106.35 to inside:192.168.111.182/5060 from INVITE message
2009-07-01 15:44:53    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Signalling UDP secondary channel for 
outside:67.220.106.35/5060 to inside:192.168.111.182 from INVITE message
2009-07-01 15:44:53    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Signalling UDP secondary channel for 
outside:67.220.106.35 to inside:192.168.111.182/5060 from Response 4xx 
message
2009-07-01 15:44:53    Local4.Info    192.168.111.1    %PIX-6-607001: 
Pre-allocate SIP Via UDP secondary channel for outside:67.220.106.35 to 
inside:192.168.111.182/5060 from ACK message

       It appears that the failure attempt does not contain the same 
Response 100/180 commands as the successful one.

Anyway, if someone sees something obvious, please let me know, it would 
be greatly appreciated.  We are stumped on this end and just really not 
sure how to proceed.

-Kayton
>
>
>
> Hi,
>
> If You don't see anything on the command line of *, there might be an
> issue with Your phone settings. I don't know anything about the nokias,
> but I *think* it might be possible, that the phone connects to anything
> other than Your * box in case of the outbond number. AFAIK the * sends a
> 404-Error back on an non existing extension. In this case the phone
> would not show up a "connection time-out". So I would check the settings
> on the phone. Or maybe You could do a network trace with tcpdump or
> ngrep to double check, that the phone really tries to connect to *.
>
> HTH,
>
> Karsten
>
>
> Am Montag, den 29.06.2009, 10:35 -0400 schrieb Kayton Sapale:
> > That's the strange thing.  Nothing shows when monitoring the service
> > in debug.  On the phone, however, I do see a "connection time-out"
> > error.  I guess this might indicate that the device is attempting to
> > connect to the service in a way different from when just dialing an
> > extension?
>