FOOD FOR THOUGHT A lot of Inbound calls getting a busy signal from Bulk VS

[LitleBill]

It started 3 weeks ago but last 2 days it got worse.

Calls don't even go through, just hear a busy signal, and nothing shows in Asterisk log or CDR log.

Trunk shows connected, iPBX 2027 is hosted on Crown cloud.

 

[LitleBill]

Here is another leg

 

[twinclouds]

This had happened to me also. In my case, the inbound calls worked fine with my established asterisk server that I built long time ago. However, after I constructed another asterisk PBX on another Linux box, the incoming call stopped working on the new PBX. Same as in your case, I could not observe anything come in to the new server. BTW, it only happened for the incoming call. The outgoing calls always work fine. I think one possibility is that sometimes I had two PBXes on the same localnet logged into Bulkvs, the Bulkvs server might get confused and only use one of them. Another possibility is that it appears to me the Bulkvs system has some memory. It would remember one PBX and refuse to work with a new, or modified, one, for some time. So right now, once I got one PBX working, I just stick with it. (I know this is not the situation we would want ;-) )

I don't know what is your situation. But you can always contact their customer service when it does not work for you. They are usually quite helpful. At least they will tell you what they observe on their side. It would be helpful for your debugging.

 

[LitleBill]

I appreciate your comment. I would think that if you use IP authentication and both of your PBX's have the same Public IP it could get dicey with registrations. I guess you could try different SIP ports but I am no expert here.

Mine is just the recommended Nerdvittle setup using a Crown cloud VPS and PJSIP trunk.

 

[dallas]

I would think that if you use IP authentication and both of your PBX's have the same Public IP it could get dicey with registrations.

I would not expect that setup to work without using different ports for sip and with port forwarding in your firewall. In any case I'd be inclined not to trust it.

 

[twinclouds]

I appreciate your comment. I would think that if you use IP authentication and both of your PBX's have the same Public IP it could get dicey with registrations. I guess you could try different SIP ports but I am no expert here.

Mine is just the recommended Nerdvittle setup using a Crown cloud VPS and PJSIP trunk.

I agree. However, what I don't understand is that even if I have removed the previous working one and replace it with a new one with the same hardware and software, i.e., the same asterisk inplementation but with another yet identical hardware, still the replacement did not work. If I plugged in the original one back, it immediately works. Other voip providers, e.g., voip.ms do not have this problem.

 

[dallas]

I agree. However, what I don't understand is that even if I have removed the previous working one and replace it with a new one with the same hardware and software, i.e., the same asterisk inplementation but with another yet identical hardware, still the replacement did not work. If I plugged in the original one back, it immediately works.

In which case it's most likely a configuration issue with the replacement pbx. Double check all the configs you migrated the the new hardware.

 

[kenn10]

If you are using pjsip for your Bulkvs trunk, make sure you have sip.bulkvs.com on the trunks advanced tab like this:

 

[twinclouds]

In which case it's most likely a configuration issue with the replacement pbx. Double check all the configs you migrated the the new hardware.

Everything is exactly the same as I have alredy said!

 

[dallas]

Everything is exactly the same as I have alredy said!

This is not a debate. It was a suggestion. You have not provided enough information to diagnose your problem. I’m out.

 

[twinclouds]

I know it does not make sense. I gave up already. Just keep what working for me.

 

[twinclouds]

I know it does not make sense. I gave up already. Just keep what working for me.

I did some more experiments, and I think I found the problem as described below.
What I did was the following: I have one Asterisk PBX, which works fine on my BulkVS account. I then implemented another Asterisk PBX on a new Linux box. Both of them have the same hardware and software implementations. I moved the one that was previously working offline and put the new one online and it registered fine. My phone now connected to the new PBX did not ring when I called in, but it can make outgoing call with no problem at all. The CLI of new asterisk PBX did not show any signal that came in either.
As both of the PBXes have the same hardware and software implementations, the only difference between them is their localnet IP addresses. I then changed the localnet IP address of the new Asterisk PBX to be the same as the one used by the working PBX. Sure enough, I can receive incoming call without problem.
I guess the reason was that, after the new PBX implementation was put online, it registers fine with BulkVS's server. Their server used the new local IP address for the outgoing calls. However, the incoming calls were still being sent to the old localnet IP address and because the old PBX is already offline, the signal had nowhere to go.
I don't know how their server implementation would handle the situation described above. Once the registration localnet IP address changed, how long it would take their server to change the local IP address for the incoming calls to the registered address. I hope they can makeit not too long as I have observed other voip providers change the DID localnet address almost immediately to be the same as the registered address.

 

[dallas]

Well spotted! I would have expected that BulkVS would send the calls to your public IP address and your firewall would send the appropriate port(s) to the correct localnet IP. I suspect that BulkVS sends all calls via port 5060.

 

[kenn10]

If you have two PBXs behind the same router on the same external IP address and you use the same SIP/PJSIP port on both, the problem is in your local router. Bulkvs sees only one external IP address and it is up to your router to get the inbound traffic to the correct PBX. If both PBX's use port 5060 or 5061, of course Bulkvs and your phones were confused. You can't have two identical systems running the same port configuration at the same time. When you switch from one to the other, you need to reboot the router so its internal routing resets and points the SIP port to the correct PBX.

 

[Samot]

Yeah but @LitleBill is the original OP and their problem is not @twinclouds problem. @LitleBill's issue is the PBX is trying to auth challenge incoming calls.

 

[Samot]

I guess the reason was that, after the new PBX implementation was put online, it registers fine with BulkVS's server. Their server used the new local IP address for the outgoing calls. However, the incoming calls were still being sent to the old localnet IP address and because the old PBX is already offline, the signal had nowhere to go.

This is not true at all. You have two options with BulkVS, you are either doing use/pass registration or your are doing IP Auth. In either of those cases your local network IP (i.e. the one behind NAT on RFC1918 space) is irrelevant.

Additionally, there is an actual setting in the PBX for your External Media setup and where you define the local networks, that setting is called "localnet" (chan_sip) and "local_net" (chan_pjsip). The local networks defined in that setting will tell the PBX that when it receives a request for an external destination and the request is coming from an IP in the localnet setting, use the external media information in the SIP message.

So one of two things are happening here. First, improper NAT setup on the PBX. It isn't using the external media details when sending a REGISTER to BulkVS, therefore BulkVS gets a contact location with a private IP space. You can't route traffic over the public Internet to a private IP space. Second, you have a firewall NAT rule that was sending requests from BulkVS to a specific local IP in the network. An IP that was assigned to the old PBX and thus the NAT rule was sending traffic to a dead IP and by changing the current PBX to that IP, boom traffic hits it.

This doesn't seem like a BulkVS problem at all but an issue with how you setup the new PBX and the firewall/NAT changes that needed to go with it.

 

[twinclouds]

Yeah but @LitleBill is the original OP and their problem is not @twinclouds problem. @LitleBill's issue is the PBX is trying to auth challenge incoming calls.

Thanks for pointing out.
Yes. I understand. Do you think I need to open a new tread or I can continue to this one as they both related to BulkVS?

 

[twinclouds]

This is not true at all. You have two options with BulkVS, you are either doing use/pass registration or your are doing IP Auth. In either of those cases your local network IP (i.e. the one behind NAT on RFC1918 space) is irrelevant.

Additionally, there is an actual setting in the PBX for your External Media setup and where you define the local networks, that setting is called "localnet" (chan_sip) and "local_net" (chan_pjsip). The local networks defined in that setting will tell the PBX that when it receives a request for an external destination and the request is coming from an IP in the localnet setting, use the external media information in the SIP message.

So one of two things are happening here. First, improper NAT setup on the PBX. It isn't using the external media details when sending a REGISTER to BulkVS, therefore BulkVS gets a contact location with a private IP space. You can't route traffic over the public Internet to a private IP space. Second, you have a firewall NAT rule that was sending requests from BulkVS to a specific local IP in the network. An IP that was assigned to the old PBX and thus the NAT rule was sending traffic to a dead IP and by changing the current PBX to that IP, boom traffic hits it.

This doesn't seem like a BulkVS problem at all but an issue with how you setup the new PBX and the firewall/NAT changes that needed to go with it.

Hi! Thank you for your explanation. What you said made perfect sense. Actually, BulkVS also gave me the same answer but not as clean as you said. Based on yours and BulkVS's explanations, I added the rules to open 5060 port 5060 to the BulkVS's server ip addresses. It works fine now for any localnet ip address. Thanks again!

 

[twinclouds]

Hi! Thank you for your explanation. What you said made perfect sense. Actually, BulkVS also gave me the same answer but not as clean as you said. Based on yours and BulkVS's explanations, I added the rules to open 5060 port 5060 to the BulkVS's server ip addresses. It works fine now for any localnet ip address. Thanks again!

I said this too soon. It worked in my previous case but not in another set using a different local ip address. In all these cases, only one Asterisk PBX is active but on different localnet IPs. Even if I opened the 5060 port for incoming calls from all of the bulkVS host ip-addresses, The Asterisk on some localnet ips work but on the others did not work.
Any suggestions for fixing and/or debugging?

 

[twinclouds]

This is not true at all. You have two options with BulkVS, you are either doing use/pass registration or your are doing IP Auth. In either of those cases your local network IP (i.e. the one behind NAT on RFC1918 space) is irrelevant.

Additionally, there is an actual setting in the PBX for your External Media setup and where you define the local networks, that setting is called "localnet" (chan_sip) and "local_net" (chan_pjsip). The local networks defined in that setting will tell the PBX that when it receives a request for an external destination and the request is coming from an IP in the localnet setting, use the external media information in the SIP message.

So one of two things are happening here. First, improper NAT setup on the PBX. It isn't using the external media details when sending a REGISTER to BulkVS, therefore BulkVS gets a contact location with a private IP space. You can't route traffic over the public Internet to a private IP space. Second, you have a firewall NAT rule that was sending requests from BulkVS to a specific local IP in the network. An IP that was assigned to the old PBX and thus the NAT rule was sending traffic to a dead IP and by changing the current PBX to that IP, boom traffic hits it.

This doesn't seem like a BulkVS problem at all but an issue with how you setup the new PBX and the firewall/NAT changes that needed to go with it.

Hi,
About what you said above, I am using registration not IP authorization. But as you said, it does not anyway.
For the "localnet" setting, I am using sip not pjsip. However, I don't see either chan_sip.conf or chan_pjsip conf files are loaded. Do I need to force them to load before I can modify anything?
All I did so far was added three iptables rules for three of their server ip addresses:
iptables -I INPUT -p udp -s 162.249.171.198 -m udp --dport 5060 -j ACCEPT
iptables -I INPUT -p udp -s 23.190.16.198 -m udp --dport 5060 -j ACCEPT
iptables -I INPUT -p udp -s 76.8.29.198 -m udp --dport 5060 -j ACCEPT
This may be insurfficient? Is there anything else that I can do? Please advise. Thanks!