[Asterisk-Users] Beeps during Sip to Sip phone calls

[Rich Adamson]

Inline...

> I keep hearing DTMF type beeps when on phone calls, I know this is some sort 
> of trait of VOIP but it's driving me nuts..

Not really.

> I noticed that it happens MUCH more when I am on the phone with one 
> particular person.
> 
> We are using SPA-2000's from Sipura on both ends.

I'm using a spa-3000 and have noticed the same thing. Some voices
trigger it, others don't. It hasn't happened often enough to cause
me to spend time on it. (I have the spa3000 configured so that 
incoming fxo calls go directly to the fxs port (not through *), so
in my case the dtmf-like bursts have to be internal spa issues.
Since the spa2000 and 3000 share a lot of the same code base, the
tones you're hearing are likely internal spa issues as well.)
 
> Tonight I was looking at the CLI (*command line interface) while I was on 
> the phone with this person.
> 
> Each time I heard a beep, I saw at EXACTLY the same time the following line:
> 
>     -- Attempting native bridge of SIP/206-5286 and SIP/109-fbf7
> 
> What's wierd is that we were already on the phone, I was 206 and he was 109. 
> Does this give anyone a clue as to what might be happening here?
> 
> I also saw a bunch of these but not sure if it was related to our call or 
> not.
> 
> Apr  6 21:16:03 NOTICE[3587]: rtp.c:430 ast_rtp_read: RTP: Received packet 
> with bad UDP checksum
> Apr  6 21:16:05 NOTICE[3587]: rtp.c:430 ast_rtp_read: RTP: Received packet 
> with bad UDP checksum
> Apr  6 21:16:39 NOTICE[3587]: rtp.c:430 ast_rtp_read: RTP: Received packet 
> with bad UDP checksum
> Apr  6 21:16:41 NOTICE[3587]: rtp.c:430 ast_rtp_read: RTP: Received packet 
> with bad UDP checksum
> Apr  6 21:16:44 NOTICE[3587]: rtp.c:430 ast_rtp_read: RTP: Received packet 
> with bad UDP checksum
> Apr  6 21:17:03 NOTICE[3587]: rtp.c:430 ast_rtp_read: RTP: Received packet 
> with bad UDP checksum
> Apr  6 21:17:10 NOTICE[3587]: rtp.c:430 ast_rtp_read: RTP: Received packet 
> with bad UDP checksum

I'd guess the above messages are simply damaged packets (eg, ethernet
collisions, broadband hits). Since there are multiple seconds between
most of those messages, I would doubt that you would actually notice
the hits in the audio.