• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Call result: Invite request no response or Forbidden

Status
Not open for further replies.

UnDutchable30

Customer
Joined
Aug 8, 2018
Messages
62
Reaction score
3
My 3CX is hosted in the cloud with OVH and is located in Germany. My SIP provider is Weepee in Belgium. My IP-address is registered correctly at Weepee as I see the IP-address of the 3CX install in their portal.

Inbound calls work, outbound calls don't work. Here I get either Invite request no response error or Forbidden.

In the Dashboard of 3CX I only see these kind of errors:
Call or Registration to 0031611xxxxxx@(Ln.10000@Weepee) has failed. 35.190.216.220 replied: 403 Forbidden; from IP:35.190.216.220:5060

Call or Registration to 004920151xxxxxx@(Ln.10000@Weepee) has failed. 35.205.148.73 replied: 403 Forbidden; from IP:35.205.148.73:5060

I don't recognize the IP-address 35.205.148.73 and I don't know where to search for a problem. It did work however and I am not aware of any changes to the settings, so are really wondering what can cause this problem.

The firewall test in 3CX shows everything in green, so no errors here on firewall issues, but still something seems to be wrong

Hope somebody has a good advise.
 
Well a tracert to 35.205.148.73 shows it resolving to 73.148.205.35.bc.googleusercontent.com so I'm not sure why you are getting that. I would speak you your provider to confirm that your settings are in-line with what they expect. In most cases, a Forbidden message is returned because you are sending an incorrect digits format, or you are simply not permitted to dial those digits. There may be something else going on that they can shed some light on. I'm going to assume that outgoing has never worked, this is not a new issue arising from some change.
 
I believe WeePee is a supported provider, did you use the 3CX template to configure? Did you follow this guide?:

https://www.3cx.com/docs/weepee-belgian-sip-trunk/

Your description makes it sound like you are doing an IP authenticated trunk but the 3CX site says Weepee uses registration-based trunk. So when you say you see your 3CX IP in their portal do you mean it shows as registered? If the trunk is in fact registered and you can receive calls then outgoing call failures are typically a problem with your outbound rules/number formatting. You should talk to WeePee support to see why outbound calls are failing.
 
I believe WeePee is a supported provider, did you use the 3CX template to configure? Did you follow this guide?:

https://www.3cx.com/docs/weepee-belgian-sip-trunk/

Your description makes it sound like you are doing an IP authenticated trunk but the 3CX site says Weepee uses registration-based trunk. So when you say you see your 3CX IP in their portal do you mean it shows as registered? If the trunk is in fact registered and you can receive calls then outgoing call failures are typically a problem with your outbound rules/number formatting. You should talk to WeePee support to see why outbound calls are failing.

No, I really do a registration based authentication. I am awaiting for a response from Weepee for the error messages. Inbound works, but outbound not and also not on both numbers. One number I can make outbound calls, the other number not, and both use the same Weepee trunk.

Problem is that I don't see any logic in the error behavior.
 
One number I can make outbound calls, the other number not, and both use the same Weepee trunk.

If outgoing calls are using the same trunk, it sounds like a caller ID issue, that would (should), be the only difference.
 
@leejor probably nailed it. WeePee does not support 'clip no screening' so if you are sending out incorrectly formatted caller-id or caller-id for a number not assigned to you by Weepee they are probably rejecting the call.

Sorry you are waiting for a response from Weepee. I'd offer my services we only really serve North America at this point.
 
Thank all so far. I have been in touch with Weepee and we have initially adjusted the siptrunk. Although 3CX stated they do support SIP DNS SRV, Weepee told me that this does not work well, so I had to choose an alternative SIP-trunk.

Unfortunately this did not solve the problem either, so ended now with the IP-address instead of the domainname and now the siptrunk registers again.

Additionally I checked with OVH, the cloud hoster, and they don't see any problems on server side.

I did restore a backup and updated the trunk with the ip-address and now incoming calls arrive, but again no outgoing calls happen, but....
If I use the 3CX app on my mobile phone in the wifi network I can make outbound calls, but from my Yealink desktop phone or Snom desktop not. The call still ends with invite request no response and I really have no idea what to check now.

The firewall check is all green, the firewall has all the ports open, the deskphones are registered en receive the calls, just outbound is not working.

Anybody a good tip?
 
Although 3CX stated they do support SIP DNS SRV, Weepee told me that this does not work well, so I had to choose an alternative SIP-trunk.

So I'm not sure what this statement means. Does this mean you aren't using WeePee or you picked a different trunk template but are still using WeePee? And I'm not sure what Weepee means but I doesn't work well. Are they saying they don't work well with 3CX? DNS SRV is a process for determining the server and method used to connect. So if it doesn't work well, that's likely on Weepee's side because of an improper configuration of their DNS records. And even then outbound calling has nothing to do with that anyways once the trunk is registered.

For your outbound calling issues, is the 3CX app, the Yealink phone and Snom phone all on the same extension or are they different extensions?
 
So I'm not sure what this statement means. Does this mean you aren't using WeePee or you picked a different trunk template but are still using WeePee? And I'm not sure what Weepee means but I doesn't work well. Are they saying they don't work well with 3CX? DNS SRV is a process for determining the server and method used to connect. So if it doesn't work well, that's likely on Weepee's side because of an improper configuration of their DNS records. And even then outbound calling has nothing to do with that anyways once the trunk is registered.

For your outbound calling issues, is the 3CX app, the Yealink phone and Snom phone all on the same extension or are they different extensions?

Sorry for the unclarity. I am still using Weepee, but not the redundant sip and the DNS resolving seems not to work between 3CX and Weepee.

I am using now a second so route and the trunk is now registered.

The app has the two extensions as well as the Yealink. Snom has a different extension. I think that something is now wrong in the Yealink, but there nothing has changed. I don't see any logic in the problem with outbound.
 
@leejor probably nailed it. WeePee does not support 'clip no screening' so if you are sending out incorrectly formatted caller-id or caller-id for a number not assigned to you by Weepee they are probably rejecting the call.

Sorry you are waiting for a response from Weepee. I'd offer my services we only really serve North America at this point.
Clip no screening had only something to do when I would route an incoming call to outbound again, which is not the case, I just make an outbound call
 
Actually clip no screening applies to any scenario where you are presenting a CID not associated with an account. While this most commonly happens in the scenario you describe where you forward a call to a cell phone and try to preserve the originator CID if you have something on the trunk or extension level that's not associated to your account it would have the same problem. And if you had an incorrect caller-id like putting a name in there instead of just the number that can also cause calls to fail.
 
Sorry for the unclarity. I am still using Weepee, but not the redundant sip and the DNS resolving seems not to work between 3CX and Weepee.

So if DNS SRV isn't working then Weepee needs to fix it, needs to have 3CX change the template to not use DNS SRV or needs to stop being a 3CX supported provider. But in the meantime as long as it's registered we can ignore that part since it's not relevant to the outbound calling problem.

The app has the two extensions as well as the Yealink. Snom has a different extension. I think that something is now wrong in the Yealink, but there nothing has changed. I don't see any logic in the problem with outbound.

Can you be more specific as far as the actual extension numbers? And is the Snom and Yealink phones 3CX provisioned? Basically what I want to see is if you have extension 100 and it works when calling out from the app but the Yealink and Snom on different extensions fails is if you have anything set at the extension level for caller-id and if so, what is different between the working and not working extensions.
 
Hello @UnDutchable30

Please note that 3CX supports DNS SRV records and it works with Weepee as well. It was actually Weepee that requested we include the SRV record in the template to enable redundancy. Also reading your original post i assumed that the trunk was registered as inbound calls were working so at what point was the DNS resolution not working?
As you are now using an IP and you still face the same issue it is safe to assume that DNS is not causing the issue.
The error you are receiving does originate from Weepee as it is one of their IPs so they should be able to tell you what it is they do not like in the Invite.
Code:
UDP-SRV RECORDS:
        _sip._udp.sip.voice.weepee.io. 3599 IN SRV 10 50 5060 sip0-a.voice.weepee.io.  (35.189.244.98 )
        _sip._udp.sip.voice.weepee.io. 3599 IN SRV 10 50 5060 sip0-b.voice.weepee.io.  (35.190.216.220 )
        _sip._udp.sip.voice.weepee.io. 3599 IN SRV 10 50 5060 sip0-c.voice.weepee.io.  (35.205.148.73 )
        _sip._udp.sip.voice.weepee.io. 3599 IN SRV 10 50 5060 sip0-d.voice.weepee.io.  (146.148.114.244 )

Clip no screening had only something to do when I would route an incoming call to outbound again, which is not the case, I just make an outbound call
Clip no screening can occur during outbound calls as you can set a different caller ID to be sent so i would make sure this is not the case.
Since you can perform outbound calls with the 3CX client then i would check the IP phones and how they are provisioned. Make sure that you used the default 3CX template and you are running the latest supported firmware.
You could also run a capture and see what the 3CX client is sending and what the IP phone is sending to determine what is causing the issue.
 
Thanks to all with your valuable input. I would like to give some feedback about the latest findings in order to learn and exchange knowledge.

1. I have setup my Weepee SIP trunk with the fixed IP-address as their sip.voice.weepee.io with SRV did cause errors (according their statement) and also the alternative sip0-1.voice.weepee.io did not want to register. According Weepee this is because my 3CX instance at OVH has DNS problems! I contacted OVH and they don't see any issues with my instance, so I am stuck between two suppliers who both point to eachother and tell me to solve the problem with 3CX, great, but not really.
==>at least with the fixed IP-address I can receive calls again, but I doubt if Weepee has setup their network appropriately...

2. Following the fixed IP-address I got the the SIP-trunk to green again The 3CX softclient and my SNOW and Yealink Dect phones could then make call outbound calls again, but my Yealink phone not. I reprovisioned the Yealink again and still not working. Going through the phone config I noticed that the reserved ports where 14000-14009, so outside my RTP range of 9000-10999. hHen I looked in the provisioning settings in 3CX I noticed here as well that the RTP was 14000-14009. Very weird, never touched this. Changed it to 9000-10999 and reprovisioned and guess what, I could make outbound calls again from my Yealink phone.
==>Outbound calls for 1 number now works on all phones

3. The second line/account on my Yealink has still problems with outbound calls. The same error pops up "Invite request no response". I can capture the not-working call in a pcap format, but I have no experience reading the output? I checked all the settings of the second account on the same phone, but can't see any strange things. Via the 3CX app on my mobile phone in the same network I can make calls via the second line/account, but just not on the Yealink
So for this topic a suggestions is welcome!


@YiannisH_3CX : First problem was that Weepee was not registered at all, so had a red status, By changing to sip0-a the problem partially went away and when changing to the IP-address the problem was solved, So the siptrunk does register something, but is not stable. Their statement is:
"Via DNS SRV hebben we een betere redundantie maar nog niet alle centrales hebben hiervan een correcte implementatie, ook 3cx heeft hier nog wat problemen mee, ondanks dat 3cx interop onze switches, alsook DNS SRV connectei heeft getest en goedgekeurd."
Translated:
"Via DNS SRV we have better redundancy, but not yet all PBX have a correct implementation, also 3CX has still problems, although 3CX interop has tested our switches and also DNS SRV connections were tested and approved"
 
Last edited:
2. Following the fixed IP-address I got the the SIP-trunk to green again The 3CX softclient and my SNOW and Yealink Dect phones could then make call outbound calls again, but my Yealink phone not. I reprovisioned the Yealink again and still not working. Going through the phone config I noticed that the reserved ports where 14000-14009, so outside my RTP range of 9000-10999. hHen I looked in the provisioning settings in 3CX I noticed here as well that the RTP was 14000-14009. Very weird, never touched this. Changed it to 9000-10999 and reprovisioned and guess what, I could make outbound calls again from my Yealink phone.
==>Outbound calls for 1 number now works on all phones

First rule of troubleshooting is to make 1 change at a time and test. You need to stick with a STOCK 3CX setup configuring everything has it should be. At this point I have no idea what state your trunk config is, or your phones. Basic understanding of VoIP would tell you that provisioning your phone, not changing the RTP ports fixed the issue. RTP is responsible for audio AFTER the call is setup. So if you couldn't make a call, you can change anything you want with the RTP ports and that's not going to solve the issue. SIP is responsible for the call setup. This video may help:

https://www.3cx.com/blog/voip-howto/sip-overview/

As far as the ports go, it's basic networking. For two devices to talk to each other they need a free port. On the 3CX SERVER side, it originates and request return traffic on 9000-10999. This has nothing to do with the client (phone). In the case of your remote (STUN) phone, 3CX configured your phone to use 14000-14009 for originating RTP traffic and then requesting return traffic. You should be forwarding the SIP and RTP ports in the extension configuration to that phone, and you should be using unique ranges per phone if you have multiple behind the same firewall. See this guide on STUN phones.

https://www.3cx.com/docs/manual/configuring-ip-phones/#h.ul2fzupi6t22/

I'd start from scratch and try to get a stock 3CX setup working. The problem you have right now is even if things are working, you have a non-standard setup with a bunch of one-off changes. Six months from now you might not remember half of what you did and then if something breaks you won't have a decent reference point to work off of.
 
  • Like
Reactions: YiannisH_3CX
@UnDutchable30

When configuring a STUN phone in the management console the phone is allocated the default RTP ports (14000-14009). These ports as well as the SIP port should be different for each STUN phone in the same location. RTP range 9000-10999 is used by the PBX to communicate with external sources.
As @cobaltit mentioned RTP changes should have nothing to do with the call being established but glad to see you got it working.
The second account on the phone is still not working as it has been manually configured and probably using the same SIP and RTP ports other phones are using in the network. https://www.3cx.com/3cxacademy/videos/intermediate/configuring-remote-extensions/
 
Status
Not open for further replies.
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.