News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Frequent Ghost Calls / Dead Air on Answer (with logs!)

Started by managerharry, July 07, 2020, 01:23:46 PM

Previous topic - Next topic

managerharry

Obi200 with Google Voice. Frequent issues with ghost calls -- incoming calls ring on the Obi attached phone but when I answer there is only dead air.  Those calls sometimes continue to ring through on my GV linked cell where I can answer them successfully if I am quick enough.

In order to bring as much information to the table as possible I made a Google Sheet with a timestamp script where I have logged and date stamped the problems with some incoming calls, an Excel XLSX export of that sheet is attached to this post. Please note, this sheet represents only a tiny portion of the incoming calls I have had an issue with.

Also noted are some instances of static either when flashing between calls or occasionally when answering a call or having a call drop to static.

Before you suggest posting this to the Google forum, I have already done that, and they suggested I post here, so here goes.

BGood

I have had similar problems with our historical household phone number after porting to Anveo and configured for the Obi202.  The accompanying graphic shows the overwhelming number of short duration calls, mostly dead-air but some robo, relative to longer duration calls with a human on the calling end.  This analysis was made on the Anveo SIP rather than Google Voice where the number of dead-air calls seems to be somewhat less frequent.

In a previous posting, one of the Obi/GV heros here suggested that the dead-air calls may be SIP scanners, but I never followed-up with an analysis to determine the nature of the calls.  

On my to-do list is creation of a .csv "white list" file from my Outlook contacts to upload into Anveo's call treatment (call flow) system, but I have not gotten around to this yet.  If I understand the concept, the dead-air calls will not even ring through to the Obi, which would be nice.  That is unless the software initiating the call successfully spoofs caller ID to be one of the white list numbers, which sometimes happens.

drgeoff

SIP scanning calls go directly into the OB, not via GV or any other Internet Telephony Service Provider.  Thus in managerharry's case, calls that "continue to ring through on my GV linked cell" cannot be from SIP scanners.

There are several techniques* to combat SIP scanning.  There is the 'X_AcceptSipFromRegistrarOnly' setting in current OBis which can be enabled for each SP Service.

(* See http://www.obitalk.com/forum/index.php?topic=5467.0)

managerharry

I don't think it's SIP scanning for this reason: most of these calls are from known numbers and they will usually call back a few minutes or seconds later and will connect successfully.

managerharry

Turned on the syslog feature.  Here's an exerpt of the log showing a problem with an incoming call.  On the first answer I got dead air.  They called back a few seconds later and the call successfully connected.  Call numbers have been anonymized.  And just to repeat-- these are legit calls that I want to receive, not spammers or sip scanners.   

192.168.0.14   Aug 17 09:50:20      kern   debug      OB==>CRLFCRLF
192.168.0.14   Aug 17 09:50:20      kern   debug      OB:<==CRLF
192.168.0.14   Aug 17 09:50:20      kern   debug      OB:<==CRLF 1
192.168.0.14   Aug 17 09:50:21      kern   debug      CCTL:NewCallOn Term 1[0] ->,BIHDQOCGGAYU4QK2LEYVCMS7GEJBIMBVGM4TQNZWGU3DGOBQHE4TOOJYHE2DK==
192.168.0.14   Aug 17 09:50:21      kern   info   fxst_ccapi_new_call   +15555555555->15555555555 name 
192.168.0.14   Aug 17 09:50:21      kern   debug   [SLIC] CID to deliver   '' 15555555555
192.168.0.14   Aug 17 09:50:21      kern   debug      RTP:DtmfTxMtd:1(1),0
192.168.0.14   Aug 17 09:50:21      kern   debug      SIP/DLG:Start Early ICE on answering INVITE
192.168.0.14   Aug 17 09:50:21      kern   debug      RTP:Start->4a7d2757:19305(80 0);0;0;0:0:0;0(44)
192.168.0.14   Aug 17 09:50:21      kern   debug      RTP:Set actpass 2
192.168.0.14   Aug 17 09:50:21      kern   debug      DTLS:Setup active
192.168.0.14   Aug 17 09:50:29      kern   debug      [SLIC]:Slic#0 OFF HOOK
192.168.0.14   Aug 17 09:50:29      kern   info      [CNG] cng_det_init 0.
192.168.0.14   Aug 17 09:50:29      kern   debug   [DSP]   set FXS(0) DTMF detection level to (3)
192.168.0.14   Aug 17 09:50:29      kern   debug      RTP:Start->4a7d2757:19305(80 160);0;0;0:0:0;0(44)
192.168.0.14   Aug 17 09:50:29      kern   debug      RTP:Set actpass 2
192.168.0.14   Aug 17 09:50:41      kern   debug      [SLIC]:Slic#0 ONHOOK
192.168.0.14   Aug 17 09:50:41      kern   debug      RTP:Del Channel
192.168.0.14   Aug 17 09:50:45      kern   debug      [SLIC]:Slic#0 OFF HOOK
192.168.0.14   Aug 17 09:50:45      kern   info      [CNG] cng_det_init 0.
192.168.0.14   Aug 17 09:50:45      kern   debug   [DSP]   set FXS(0) DTMF detection level to (1)
192.168.0.14   Aug 17 09:50:45      kern   debug      [CPT] --- FXS h/w tone generator (dial)---
192.168.0.14   Aug 17 09:50:48      kern   debug      [SLIC]:Slic#0 ONHOOK
192.168.0.14   Aug 17 09:50:50      kern   debug      OB==>CRLFCRLF
192.168.0.14   Aug 17 09:50:50      kern   debug      OB:<==CRLF
192.168.0.14   Aug 17 09:50:50      kern   debug      OB:<==CRLF 1
192.168.0.14   Aug 17 09:50:54      kern   debug      CCTL:NewCallOn Term 1[0] ->,BIHDQOCGGAYU4QK2LEYVCMS7GEJBIMBVGM4TQNZWGU3DGOBQHE4TOOJYHE2DK==
192.168.0.14   Aug 17 09:50:54      kern   info   fxst_ccapi_new_call   +15555555555->15555555555 name 
192.168.0.14   Aug 17 09:50:54      kern   debug   [SLIC] CID to deliver   '' 15555555555
192.168.0.14   Aug 17 09:50:54      kern   debug      RTP:DtmfTxMtd:1(1),0
192.168.0.14   Aug 17 09:50:54      kern   debug      SIP/DLG:Start Early ICE on answering INVITE
192.168.0.14   Aug 17 09:50:54      kern   debug      RTP:Start->4a7d2732:19305(80 0);0;0;0:0:0;0(44)
192.168.0.14   Aug 17 09:50:54      kern   debug      RTP:Set actpass 2
192.168.0.14   Aug 17 09:50:54      kern   debug      DTLS:Setup active
192.168.0.14   Aug 17 09:50:54      kern   debug      DTLS:Handshake Success
192.168.0.14   Aug 17 09:50:55      kern   debug      RTP:PeerRflxAddr=4a7d2732:19305
192.168.0.14   Aug 17 09:50:56      kern   debug      SRTCP:index=80000001
192.168.0.14   Aug 17 09:50:56      kern   debug      RTCP:RxMuxPkt[40]=200<--4a7d2732:19305
192.168.0.14   Aug 17 09:51:01      kern   debug      [SLIC]:Slic#0 OFF HOOK
192.168.0.14   Aug 17 09:51:01      kern   info      [CNG] cng_det_init 0.
192.168.0.14   Aug 17 09:51:01      kern   debug   [DSP]   set FXS(0) DTMF detection level to (3)
192.168.0.14   Aug 17 09:51:01      kern   debug      RTP:Start->4a7d2732:19305(80 160);0;0;0:0:0;0(44)
192.168.0.14   Aug 17 09:51:01      kern   debug      RTP:Set actpass 2
192.168.0.14   Aug 17 09:51:01      kern   debug   [JB]   switching ssrc -- curr: 5868203f, new: ec8cef4b
192.168.0.14   Aug 17 09:51:01      kern   debug   [JB]   switching ssrc -- curr: ec8cef4b, new: 19b422e9
192.168.0.14   Aug 17 09:51:01      kern   debug      RTP:PeerRflxAddr=4a7d2732:19305
192.168.0.14   Aug 17 09:51:20      kern   debug      OB==>CRLFCRLF