It can happen to a call that comes in over zap and is answered on one of the sip phones, or on a call that goes out over iax from one of the sip phone. There seems to be no patter / rhyme / reason.
Users will be mid conversation and suddenly the remote party can no longer hear them. If the remote party doesn’t hang up first, the audio may return.
Normally, I would assume a problem like this is being caused by a flakey VoIP service, but as I mentioned it can happen on a call that comes in over zap, where the only VoIP is on the local netowrk, between asterisk and the phones.
Last night I upgraded asterisk to see if it would fix the problem, but when i spoke to one of my users today they told me it had already happened.
What do you see when you have rtp debug enabled ?
The common factor is they are all SIP calls for at least one leg.
Ian
[quote=“ianplain”]What do you see when you have rtp debug enabled ?
The common factor is they are all SIP calls for at least one leg.
Ian[/quote]
It happened on Friday, but I didn’t have rtp debug enabled. I’ll have it ready on Monday.
One thing I have noticed is that I loose some packets when I traceroute, mostly at the gateway at that location. Sometimes it’s worse than others. For instance, when I was posting about this on Thursday I lost my ssh connection several times. However I haven’t lost it since.
Since Friday, here are my traceroute results for the ‘bad location’:
[code]Host Loss% Snt Drop Last Avg
-
up4.linode.com 0.0% 21271 26 0.4 0.3
- vl1.dsr01.dllstx2.theplanet 0.0% 21271 42 0.4 0.3
- te9-4.dsr01.dllstx3.theplan 0.0% 21271 1 0.5 0.5
- et5-1.ibr03.dllstx3.theplan 0.0% 21271 6 0.5 0.4
- 68.86.88.49 0.0% 21271 2 1.4 1.1
-
pos-0-8-0-0-cr01.atlanta.ga 0.0% 21271 2 22.4 22.3
-
pos-1-9-0-0-cr01.chicago.il 0.0% 21271 2 43.6 43.1
- 65.19.100.165 0.0% 21271 42 43.6 43.5
- ???
- ???
- ???
- ool-4353f80e.dyn.optonline. 0.0% 21271 3 56.8 56.1
- ubr202-ge1-0-0.cmts.nwrknj. 0.0% 21271 4 57.1 56.3
- ool-4354d123.dyn.optonline. 0.2% 21271 334 62.8 61.2
[/code]
.2% packetloss may not seem like a lot, but compare that to my ‘good location’ which has dropped 2230% less packets (15).
I spoke with soome people on the IPCOP forum, and they’ve assured me that communication between two clients on my LAN is not likely to be affected by the performance of the router.
Since the issue happens on inbound ZAP calls, anything on the WAN wouldn’t be to blame.
That leaves me with RTP Debug and the logs. I’ve instructed my users to call me the moment it happens next.