[asterisk-users] At whit's end was 'DHCP Failure screws up system '

[Eric Wieling]

SIP poke does NOT just measure network latency.  It also measures the 
PHONE latency.  Asterisk sends a SIP OPTIONS packet to the phone, the 
phone responds, Asterisk measures how long it took.  Most phones seem to 
make responding to OPTIONS packets a low priority.  A phone busy doing a 
registration, accepting a call, placing a call, etc and can easily cause 
the phone to take 2000ms or more to respond to the OPTIONS packet. 
Remember, most of these phones have so little general CPU power they can 
easily be overwhelmed by SIP traffic.  Most phones have a dedicated chip 
to handle audio encoding/decoding, so audio would not normally be 
affected by the general CPU being bogged down.

Doug Lytle wrote:
> Eric Wieling wrote:
>> Doug Lytle wrote:
>>   
>> Based on the SIP poke message you pasted in an earlier message, the 
>> qualify= option you used is virtually guaranteed to cause SIP poke problems.
>>
> Understood, wouldn't it also indicate that, when putting 2 phones and 
> the phone system on it's own little switch and I still see the SIP poke 
> messgages that it's something to do with either the Polycoms or the system?
> 
> Just struggling to understand what is going on.
> 
> On the norm, we've never had anything above 60ms.  Taking out the 
> qualify worked briefly.  FOP showed statuses fine.  The they started 
> dropping out and phones were unable to receive/make calls.
> 
> Also, I replace the NIC and it made no difference and using 2 NICs (1 
> for 192.x.x.x and one for the 10.10.10.x networks) instead of 2 IPs on 
> one interface made no difference either.
> 
> I guess I go back to plan A and replace the machine.

---
Consulting for Asterisk, Polycom, Sangoma, Digium, Cisco, LAN, WAN, QoS, 
T-1, PRI, Frame Relay, Linux, and network design.  Based near 
Birmingham, AL.  Now accepting clients worldwide.