Quantcast
Channel: VOIP Tech Chat forum - dslreports.com
Viewing all articles
Browse latest Browse all 6358

GVSIP/Asterisk/Freepbx 503 error on voice mail handoff

$
0
0
I believe this was touched on on the main gvsip thread and/or on the freepbx forum in the how to guide (https://community.freepbx.org/t/how-to-guide-for-google-voice-with-freepbx-14-asterisk-gvsip-ubuntu-18-04/50933) Pbx is configured as per the first post above. Inbound - works fine and handsoff to gv voicemail as long as the calling party is not using a*/gvsip/freepbx (from here on referred to as gvsip) If the calling party is using gvsip then it rings as normal until the handoff to vm occurs. Then a 503 error is received by the calling party. I've discovered two common factors - 1) voicemail is handled by gv 2) call initiated by gvsip Examples of failures 1) Softphone registered to pbx/gvsip calling another gv # using gvsip trunk. Call rings properly on the other side but goes unanswered. Instead of reaching voicemail, call is dropped with 503 error. 2) Calling cell phone from softphone/gvsip. Cell phone is using gv voicemail. Call rings properly but is dropped when handed off to gv vm when left unanswered. 3) Call gv # configured as trunk in pbx/gvsip from softphone connected to that pbx using same gv trunk. In the past one could listen to their voice messages or press #2 to make a call, now call is just dropped with 503 error. Examples of success: 1) Calling gv # configured in pbx/gvsip from a cellphone/landline/other voip provider. Softphone rings but goes unanswered. Standard gv vm greeting is heard and vm can be left. 2) Calling cellphone which uses gv vm for voicemail from another voip provider. Standard gv vm greeting is heard and vm can be left. 3) Calling a gv # from a gv trunk on an obi20x device. Standard gv vm greeting is heard and vm can be left. As can be seen, the 503 errors occur when asterisk/gvsip is involved in initiating the call. Specifically at the time when the handoff is made to gv voicemail. It's been alluded to that this is a gv issue. I can understand that if that was also the case with calls initiated by a obi20x box. However such calls are properly handed off to the gv vm system without getting dropped. Perhaps there's something in the gvsip call flow that is not allowing this complete properly (or at all)? I don't have the knowledge in how to approach or resolve this. Easiest way to demonstrate is just call the same gv # as configured in gvsip trunk (from itself #3 in failures above). @naf or others, any thoughts? Thanks!

Viewing all articles
Browse latest Browse all 6358

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>