SIP Phones randomly act like they're on DND

[JasonH]

I am running Asterisk 1.6.1.10. The server is internal to our network and we have about 40 extensions with SIP hard phones. There are issues with SOME extensions where you can dial the extension (both internal dial and from external) and it rings, but then sometime later it goes straight to voicemail. This has happened on multiple extensions, but not all. We are creating the extensions and configuring the phones all the same, so I'm lost why it's only happening on some.

The only way to make the extension ring again after it starts forwarding to voicemail is to dial *79 (disable dnd). These feature codes are handled by asterisk, not the phone itself. But if I look at "database show dnd" in the CLI, the extension that is going straight to voicemail doesn't appear on the list. If I look at "sip show peer xxxx" it's status is always "OK (xx ms)".

Here is the full output of sip show peer for the trouble extension:

tsunami*CLI> sip show peer 3019

  * Name       : 3019
  Secret       : <Set>
  MD5Secret    : <Not set>
  Context      : from-internal
  Subscr.Cont. : <Not set>
  Language     : 
  AMA flags    : Unknown
  Transfer mode: open
  CallingPres  : Presentation Allowed, Not Screened
  Callgroup    : 
  Pickupgroup  : 
  Mailbox      : 3019@default
  VM Extension : 2284
  LastMsgsSent : 32767/65535
  Call limit   : 2147483647
  Dynamic      : Yes
  Callerid     : "device" <3019>
  MaxCallBR    : 384 kbps
  Expire       : 2939
  Insecure     : no
  Nat          : RFC3581
  ACL          : Yes
  T.38 support : No
  T.38 EC mode : Unknown
  T.38 MaxDtgrm: -1
  CanReinvite  : No
  PromiscRedir : No
  User=Phone   : No
  Video Support: No
  Text Support : No
  Ign SDP ver  : No
  Trust RPID   : No
  Send RPID    : No
  Subscriptions: Yes
  Overlap dial : Yes
  DTMFmode     : rfc2833
  Timer T1     : 500
  Timer B      : 32000
  ToHost       : 
  Addr->IP     : 192.168.100.217 Port 5060
  Defaddr->IP  : 0.0.0.0 Port 5060
  Transport    : UDP
  Def. Username: 3019
  SIP Options  : path replaces replace timer 
  Codecs       : 0xe (gsm|ulaw|alaw)
  Codec Order  : (ulaw:20,alaw:20,gsm:20)
  Auto-Framing :  No 
  100 on REG   : No
  Status       : OK (44 ms)
  Useragent    : Grandstream BT200 1.2.5.2
  Reg. Contact : sip:[email protected]:5060;transport=udp
  Qualify Freq : 60000 ms
  Sess-Timers  : Refuse
  Sess-Refresh : uas
  Sess-Expires : 1800 secs
  Min-Sess     : 90 secs
  Parkinglot   :

And from the debug SIP dialog these are the requests that I'm seeing (in order) for a failed internal call from one SIP phone to the problem extension (3019):

INVITE sip:3019@pbx SIP/2.0
Sending to 192.168.100.221 : 5060 (no NAT)
SIP/2.0 401 Unauthorized
ACK sip:3019@pbx SIP/2.0
INVITE sip:3019@pbx SIP/2.0
Sending to 192.168.100.221 : 5060 (NAT)
SIP/2.0 100 Trying
SIP/2.0 200 OK
ACK sip:[email protected] SIP/2.0
BYE sip:[email protected] SIP/2.0
SIP/2.0 200 OK

And this is a working one:

INVITE sip:3019@pbx SIP/2.0
Sending to 192.168.100.221 : 5060 (no NAT)
SIP/2.0 401 Unauthorized
ACK sip:3019@pbx SIP/2.0
INVITE sip:3019@pbx SIP/2.0
Sending to 192.168.100.221 : 5060 (NAT)
SIP/2.0 100 Trying
SIP/2.0 180 Ringing
SIP/2.0 180 Ringing
CANCEL sip:3019@pbx SIP/2.0 (Note: I hung up after 2 rings)

I can see the difference in the SIP messages, but that doesn't tell me what's actually happening. I'm lost at what to look at next and have been on the hunt to solve this now for over a month. Anyone have any suggestions?

 

[texy]

I just fixed an issue just like this with Polycom phones, though there was no way of making the phone receive the call - looks like it was due to NAT issues even though the phones and the PBX were inside the firewall.
I am not sure which fixed the issue - but I found an error in my localnets setting, but I definitely needed to set nat=no (instead of yes) on the extension.
Now the question is why did only 2 phones out of 30+ polycom phones have this problem? And the problem was tied to the extension #; swapping in a new phone did not fix the issue.

But this might not be applicable to your problem as it looks like you have it off on the extension already? We have a bunch of Grandstream GS2000 models and haven't seen this issue.

Perhaps turn on SIP debug for one of the problem phones, make sure ringing works and then - when the problem happens again - see if the sip debug shows anything interesting.

And perhaps turn on the phones debugging and log it via syslog so you can maybe find something there when the problem re-occurs.