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?
>