When making an outbound call using Vitelity and reaching a Verizon cell phone voicemail the call just hangs. It seems the “beep” causes this but you never hear it. The call doesn’t drop but you can’t leave a message. Calling the same number with voip.ms or a POTS line and the user is able to leave a message in the mailbox. So far I have I have disabled *2, ** and ## in the feature codes module and the T option in advanced settings. Does it sound like a Vitelity issue?
The only thing in this list that should be done is contacting Vitelity. Calls to a single destination (number) over one particular carrier generally do not mean a firewall or PBX issue.
The real question here: Is this just one number or is this ALL Verizon numbers being called via Vitelity?
Based on the information provided so far, yes this seems to be a Vitelity issue. Randomly rebooting firewalls and the PBX, just because, is not a viable troubleshooting method. Reach out to Vitelity and give them the call example and timestamp of the call, they’ll be able to look at it.
Also keep in mind though, Vitelity is an aggregate and generally doesn’t touch the media (they pass it through to their upstream carrier) so they may or may not be able to give you an answer right away.
Just a guess, your PBX is offering T.38 fax, the beep sounds like a fax tone and Vitelity sends a re-invite to switch to T.38. You can verify this easily with a SIP trace. At the Asterisk command prompt, type pjsip set logger on
or sip set debug on
according to your trunk type.
Then make a failing call and the SIP will appear in the Asterisk log.
Having the same issue here. Reaching out to Vitelity as well. Was Vitelity able to identify the issue for you after you’ve reached out to them or did they blame Verizon?
show this call timed out. I show we did not receive an ACK from you in response to our 200 OK, and then your system sent a cancel:
Jul 16 9:14:23.460 AM > INVITE sip:[email protected] SIP/2.0
Jul 16 9:14:23.461 AM < SIP/2.0 100 Trying
Jul 16 9:14:25.512 AM < SIP/2.0 180 Ringing
Jul 16 9:14:25.513 AM < SIP/2.0 183 Session Progress
Jul 16 9:15:01.702 AM < SIP/2.0 200 OK
Jul 16 9:15:02.701 AM < SIP/2.0 200 OK
Jul 16 9:15:03.702 AM < SIP/2.0 200 OK
Jul 16 9:15:05.703 AM < SIP/2.0 200 OK
Jul 16 9:15:28.207 AM > CANCEL sip:[email protected] SIP/2.0
So according to Vitelity it was our system not responding to packets that they are sending? I am not sure why this only happens when we are trying to leave a VM for a Verizon call.