Page 1 of 1

Customer Voice Not Audible Gradually

PostPosted: Thu Mar 01, 2018 1:08 pm
by zenithbsolutions
Hi,

We are experiencing a strange issue today on vicibox 8.0.1. We get a live call from the customer we are able to hear the customers voice at the beginning later on we are not able to hear the customers voice.

We have no network issues on the server and there are no RTP blocks or packet loss from or to the server.

There are no errors in the asterisk but just a warning

[Mar 1 21:31:16] -- Executing [8369@default:2] AGI("SIP/voip-00004465", "agi://127.0.0.1:4577/call_log") in new stack [Mar 1 21:31:16] -- AGI Script Executing Application: (EXEC) Options: (Set(_CAMPCUST=BUSINESS)) [Mar 1 21:31:16] -- <SIP/voip-00004465>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0 [Mar 1 21:31:16] -- Executing [8369@default:3] AMD("SIP/voip-00004465", "2000,2000,1000,5000,120,50,4,256") in new stack [Mar 1 21:31:16] -- AMD: SIP/voip-00004465 15128253239 (N/A) (Fmt: slin) [Mar 1 21:31:16] -- AMD: initialSilence [2000] greeting [2000] afterGreetingSilence [1000] totalAnalysisTime [5000] minimumWordLength [120] betweenWordsSilence [50] maximumNumberOfWords [4] silenceThreshold [256] maximumWordLength [5000] [Mar 1 21:31:16] -- AMD: Channel [SIP/voip-00004465]. Changed state to STATE_IN_SILENCE [Mar 1 21:31:17]
NOTICE[2291]: chan_sip.c:29370 check_rtp_timeout: Disconnecting call 'SIP/voip-00004427' for lack of RTP activity in 61 seconds
[Mar 1 21:31:17] == Spawn extension (default, 8600062, 1) exited non-zero on 'SIP/voip-00004427' [Mar 1 21:31:17] -- Executing [h@default:1] AGI("SIP/voip-00004427", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----44---------------") in new stack [Mar 1 21:31:17] -- <SIP/voip-00004427>AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0 [Mar 1 21:31:17] == Manager 'sendcron' logged on from 127.0.0.1 [Mar 1 21:31:17] -- Executing [12345617816622100@default:1] AGI("Local/12345617816622100@default-00007d3e;2", "agi://127.0.0.1:4577/call_log") in new stack [Mar 1 21:31:17] -- AGI Script Executing Application: (EXEC) Options: (Set(_CAMPCUST=BUSINESS)) [Mar 1 21:31:17] -- <Local/12345617816622100@default-00007d3e;2>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0 [Mar 1 21:31:17] -- Executing [12345617816622100@default:2] Dial("Local/12345617816622100@default-00007d3e;2", "SIP/voip/17816622100,,tToR") in new stack"

Kindly help me or suggest me on how to crack this issue down.

Re: Customer Voice Not Audible Gradually

PostPosted: Tue Mar 06, 2018 2:34 pm
by VoIPEssential
Likely a NAT issue. If you're behind a router/firewall, make sure to open the required SIP/RTP ports. Also check the "externip" parameter in sip.conf and make sure its set to your correct public IP address. There are a ton of resources on this forum and other Asterisk related forums on how you can do this.

Re: Customer Voice Not Audible Gradually

PostPosted: Tue Mar 06, 2018 2:57 pm
by williamconley
zenithbsolutions wrote:Hi,

We are experiencing a strange issue today on vicibox 8.0.1. We get a live call from the customer we are able to hear the customers voice at the beginning later on we are not able to hear the customers voice.

We have no network issues on the server and there are no RTP blocks or packet loss from or to the server.

There are no errors in the asterisk but just a warning

[Mar 1 21:31:16] -- Executing [8369@default:2] AGI("SIP/voip-00004465", "agi://127.0.0.1:4577/call_log") in new stack [Mar 1 21:31:16] -- AGI Script Executing Application: (EXEC) Options: (Set(_CAMPCUST=BUSINESS)) [Mar 1 21:31:16] -- <SIP/voip-00004465>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0 [Mar 1 21:31:16] -- Executing [8369@default:3] AMD("SIP/voip-00004465", "2000,2000,1000,5000,120,50,4,256") in new stack [Mar 1 21:31:16] -- AMD: SIP/voip-00004465 15128253239 (N/A) (Fmt: slin) [Mar 1 21:31:16] -- AMD: initialSilence [2000] greeting [2000] afterGreetingSilence [1000] totalAnalysisTime [5000] minimumWordLength [120] betweenWordsSilence [50] maximumNumberOfWords [4] silenceThreshold [256] maximumWordLength [5000] [Mar 1 21:31:16] -- AMD: Channel [SIP/voip-00004465]. Changed state to STATE_IN_SILENCE [Mar 1 21:31:17]
NOTICE[2291]: chan_sip.c:29370 check_rtp_timeout: Disconnecting call 'SIP/voip-00004427' for lack of RTP activity in 61 seconds
[Mar 1 21:31:17] == Spawn extension (default, 8600062, 1) exited non-zero on 'SIP/voip-00004427' [Mar 1 21:31:17] -- Executing [h@default:1] AGI("SIP/voip-00004427", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----44---------------") in new stack [Mar 1 21:31:17] -- <SIP/voip-00004427>AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0 [Mar 1 21:31:17] == Manager 'sendcron' logged on from 127.0.0.1 [Mar 1 21:31:17] -- Executing [12345617816622100@default:1] AGI("Local/12345617816622100@default-00007d3e;2", "agi://127.0.0.1:4577/call_log") in new stack [Mar 1 21:31:17] -- AGI Script Executing Application: (EXEC) Options: (Set(_CAMPCUST=BUSINESS)) [Mar 1 21:31:17] -- <Local/12345617816622100@default-00007d3e;2>AGI Script agi://127.0.0.1:4577/call_log completed, returning 0 [Mar 1 21:31:17] -- Executing [12345617816622100@default:2] Dial("Local/12345617816622100@default-00007d3e;2", "SIP/voip/17816622100,,tToR") in new stack"

Kindly help me or suggest me on how to crack this issue down.

Do check what VoIPEssential suggested (externip, if this is a NAT problem), but it's also possible your carrier is sending their audio (random port above 10000 UDP) from a different IP than the control circuit (port 5060 udp). This new IP trying to send audio not being in your firewall (which will then drop the packets) will cause "no rtp traffic" and the channel dies in 61 seconds.

To test, of course, you can open all ports temporarily. If that works, grab the IP of the inbound audio and allow it through your firewall (and/or contact your carrier for a list of all possible IPs that may generate audio). This is easiest to do if you have a public IP directly on your Vicidial server (no router involved) so there's no other entity making decisions about which packets get through and which ones don't. The firewall in the Vicidial server is then the only possible "firewall problem". ;)