FOOD FOR THOUGHT BulkVS.com -- Great Origination/Termination/TF rates!

[atsak]

I have a PJSIP trunk with BulkVS.
For some reason DTMF is not sensed when I dial to a FreePBX but seems to work on other services where I use DTMF. Any idea what could be wrong?

This is often a NAT issue (only one way audio) on the firewall - which doesn't make sense but happens, though it can be a DTMF specific issue. Check port 10-20000 is open on your firewall (UDP only required), and the trunk has dtmf set to rfc2833 (should by default)

 

[kenn10]

I had a lot of PJSIP issues including inconsistent DTMF handling under Asterisk 13. I'd suggest that you look into upgrading to IncrediblePBX 2020. PJSIP is much more stable under Asterisk 16. The issues I encountered ranged from voicemail not accepting DTMF from users dialing in on a trunk to not being able to access bank services that required DTMF. It would be intermittent even though extension and trunk settings were correct. I'd usually end up changing trunking to chan_sip to fix the issue. I've not experienced any of that with IncrediblePBX 2020 and Asterisk 16 because PJSIP is working correctly now.

 

[Eliad]

This is often a NAT issue (only one way audio) on the firewall - which doesn't make sense but happens, though it can be a DTMF specific issue. Check port 10-20000 is open on your firewall (UDP only required), and the trunk has dtmf set to rfc2833 (should by default)

I looked at the Advanced tab for the BulkVS PJSIP trunk. For the DTMF there are the following options. Auto(default setting), RFC 4733 , Inband and Info. I tried all of those options. Inband is the one that works when dialing into another IncrediblePBX server (a friend of mine).

 

[Eliad]

I had a lot of PJSIP issues including inconsistent DTMF handling under Asterisk 13. I'd suggest that you look into upgrading to IncrediblePBX 2020. PJSIP is much more stable under Asterisk 16. The issues I encountered ranged from voicemail not accepting DTMF from users dialing in on a trunk to not being able to access bank services that required DTMF. It would be intermittent even though extension and trunk settings were correct. I'd usually end up changing trunking to chan_sip to fix the issue. I've not experienced any of that with IncrediblePBX 2020 and Asterisk 16 because PJSIP is working correctly now.

This happens on a InccrediblePBX2020 with Asterisk 16.12.0 just for BulkVS PJSIP trunk. If i use regular Chan-SIP trunks(Skyetel, VOIP.MS, Vitelity) to dial out it does not happen.

 

[kenn10]

I suspect that Bulkvs is doing a point-to-point IP handoff once the far end answers. Does your friend's FreePBX have their incoming trunk set for RFC4733? The fact that setting your trunk for Inband fixes the issue may point to the far-end trunk being set to inband as well.

 

[atsak]

I looked at the Advanced tab for the BulkVS PJSIP trunk. For the DTMF there are the following options. Auto(default setting), RFC 4733 , Inband and Info. I tried all of those options. Inband is the one that works when dialing into another IncrediblePBX server (a friend of mine).

RFC2833 is what you need to use BulkVS, but 4733 is fine too, I don't use PJSIP often.

BulkVS definitely does handoff the RTP after call setup, they do not proxy the media. So make sure UDP port 10 - 20000 is open from any.

 

[Eliad]

I suspect that Bulkvs is doing a point-to-point IP handoff once the far end answers. Does your friend's FreePBX have their incoming trunk set for RFC4733? The fact that setting your trunk for Inband fixes the issue may point to the far-end trunk being set to inband as well.

The receiving call trunk is a vitelity SIP trunk. There is no DTMF option set for this incoming trunk. Should I add DTMF=RFC2833 ?

 

[kenn10]

The receiving call trunk is a vitelity SIP trunk. There is no DTMF option set for this incoming trunk. Should I add DTMF=RFC2833 ?

There's no harm in trying.

 

[Eliad]

There's no harm in trying.

tried, does not change the behavior. I guess I will let the BulkVS DTMF set to inband unless you think this will screw up something else. Ports 10000-20000 are forwarded in my firewall, i do not experience one way phone connections

 

[kenn10]

DTMF set to inband should be OK. But if you access your Bulkvs via the cellular network, you may have mixed results. (Calling on your cell phone to check voice mail, etc.)

 

[Patrick68]

I have a problem with outbound calls.
I am using the sip channel with registration method.
I can receive calls, but when I am trying to dial I got a: Got SIP response 503 "Route Advance, Please" back from 76.8.29.198
Does someone has a proper trunk setup info for SIP registration?
I tried the Ward's setup without success there.

 

[Halea]

Give a try with those.
BulkVS Registred Trunk Settings:

Peer Details:
username=<UserID>
type=friend
secret=<Password>
qualify=yes
insecure=port,invite
host=sip.bulkvs.com
dtmfmode=rfc2833
disallow=all
context=from-trunk
allow=ulaw

Registration String:
<UserID>:<Password>@sip.bulkvs.com

 

[Patrick68]

thanks.
So far it's working.
The only difference I had with my prior config is I had a fromuser= in addition to the username=.

 

[Halea]

thanks.
So far it's working.
The only difference I had with my prior config is I had a fromuser= in addition to the username=.

Glad to know it works for you too.
If my memory serves me well "fromuser"'s purpose is to set the default outgoing caller id or to override it.
Some providers like voip.ms always require an outgoing caller id and that's the "forget me not" method to set it.
Many providers do not require it.

 

[dhoppy]

I have setup BulkVS for testing, and put as the outbound caller ID a number (main office number) that is with Vitelity, instead of the DID that I got from BulkVS. When I place an outbound call to my cell on Verizon, my cell phone detects it as potential spam. Is there a way to keep the main number at Vitelity but use BulkVS for outbound calls without looking like a scammer?

 

[krzykat]

I have setup BulkVS for testing, and put as the outbound caller ID a number (main office number) that is with Vitelity, instead of the DID that I got from BulkVS. When I place an outbound call to my cell on Verizon, my cell phone detects it as potential spam. Is there a way to keep the main number at Vitelity but use BulkVS for outbound calls without looking like a scammer?

That's interesting. So you are saying that both vitelity and bulkvs send the call and the callerID shows correctly both ways, but your mobile phone knows the difference and shows one as potential spam? Who is your cell phone provider? Sounds like they are using a stir/shaken and this is the big potential problem with it with VoIP services.

 

[dhoppy]

That's interesting. So you are saying that both vitelity and bulkvs send the call and the callerID shows correctly both ways, but your mobile phone knows the difference and shows one as potential spam? Who is your cell phone provider? Sounds like they are using a stir/shaken and this is the big potential problem with it with VoIP services.

Yes. That is what happened yesterday when I tested it. It showed a "potential spam" warning which is what Verizon considers a medium risk call ("potential fraud" is their warning for a high risk call). Just now when I tried it, I didn't get the warning.

 

[kenn10]

Yeah. That's what I thought would happen as SHAKEN/STIR is implemented. Eventually, sending a number that is not registered to your account will be rejected by the terminating provider. Another inconvenience brought to you by unethical spammers and robodialers. Imagine the implications for find me/follow me as endless numbers not registered to your account are sent out to the cellular network to reach you.

 

[Halea]

I have setup BulkVS for testing, and put as the outbound caller ID a number (main office number) that is with Vitelity, instead of the DID that I got from BulkVS. When I place an outbound call to my cell on Verizon, my cell phone detects it as potential spam. Is there a way to keep the main number at Vitelity but use BulkVS for outbound calls without looking like a scammer?

Most cell phone companies are providing spam detection services free of charge nowadays. They get those numbers checked by a third party as they come into their switch. For instance nomorobo offers such a spam detection service that I use in the USA for all my land lines. On mobile devices you can buy a monthly subscription and the app checks your incoming calls against their database. There are several companies offering the service.

With the proliferation of spam on cell phones and subscribers requesting for compensation for such nuisance calls (because they are actually entitled to as the paying party), the major cell companies started to offer the service free of charge. Moreover they don't even do it at your smartphone's app level, but directly off of their incoming call switch(es).

When you get a call mis-classified as spam, you need to call your provider and ask them to untag the number.
Verizon does it no questions asked, most of its MVNO's like pagepluscellular and tracphone do it too.

BulkVS also makes adjustments if you run into the same situation with a caller that you know to be legit and comes across as a spammer through their CNAM mitigation platform.
For instance a few weeks ago we got our primary care physician's appointment reminder service blocked as a robocaller. Dropped a word to BulkVS, they removed it right away from their CNAM mitigation system.

PS: So, this actually has nothing to do with SHAKEN/STIR or anything such. Termination trunk providers, especially the wholesale ones do and have to allow user provided caller id. As calls are switched from network to network all participants need to honor caller id information forwarding as there is no technical way or authority to determine which caller id is legitimate, which one is not. The FCC rules which predate the voip era require that any and all network provider or transfer agent pass through caller ids.

 

[kenn10]

Full FCC information on SHAKEN/STIR mandates: https://www.fcc.gov/document/fcc-mandates-stirshaken-combat-spoofed-robocalls