Yealink T41s receives config file via STUN but failed to register

[Nkosiedread]

Greetings,

I'm using 3CX Standard Annual 16.0.9 Debian hosted on cloud try to provision Yealink T41S using STUN.
I followed the recommended phone provisioning from https://www.3cx.com/sip-phones/yealink-t4-series/ and update the phone firmware to 66.85.0.5.
When the phone boot for the first time it does request for username and password, downloads the config files but fails to register.

I unchecked "Disallow use of extension outside the LAN (Remote extensions using Direct SIP or STUN will be blocked", no errors/notification regarding this registration from Event and Activity log.

The above is the senario when the phone is connected through a fiber broadband internet, when connected to LTE no username rquest on boo up and no config file is downloaded.


Regards,
Nkosana

Kindly adviser further.

 

[JohnS_3CX]

Hello,

In STUN mode there are some additional requirements.

If you have more than a couple of phones at that site you should consider installing an SBC as it will make life much easier.

PS: As for the LTE connection, depending on how your provider has their network and modem structured, it may be a technical impossibility to use that connection. It sounds like the phone did not even reach the internet.

 

[Nkosiedread]

Hello,

In STUN mode there are some additional requirements.

If you have more than a couple of phones at that site you should consider installing an SBC as it will make life much easier.

PS: As for the LTE connection, depending on how your provider has their network and modem structured, it may be a technical impossibility to use that connection. It sounds like the phone did not even reach the internet.

Hi John,

Thank you for your reply,

The phone gets provisioned and it downloads the config file but fails to register.

I did PCAP for registration on both the phone and pbx and I see communication between the two from both PCAPs.

I applied SIP filter I can see both IP from the phone and pbx captures but still trying to analyze them to narrow down to the problem, any ideas on which filter to apply and what to search for ?

I see communication between the two from the pbx side is loopng between,
Phone to PBX => 863 Request: INFO sip mydomain.3cx.co.za
BPx to Phone => 375 Status: 481 Call/Transaction does not exit

Any clues what that could mean ?

 

[JohnS_3CX]

That's a good first step, but please study the article above and ensure all points have been met. There are important points that could break registration.

Also, check your IP blacklist in the management console and make sure the public IP of the remote phone site has not simply been blacklisted

 

[Nkosiedread]

863

That's a good first step, but please study the article above and ensure all points have been met. There are important points that could break registration.

Also, check your IP blacklist in the management console and make sure the public IP of the remote phone site has not simply been blacklisted

Sure, let me take a deep dive to the article, see what I will come up with.

Surprising I just provisioned the exact phone from a different site and it's working fine, I'm following the same recommended procedure.

 

[Nkosiedread]

863

Sure, let me take a deep dive to the article, see what I will come up with.

Surprising I just provisioned the exact phone from a different site and it's working fine, I'm following the same recommended procedure.

Just checked the article I have been going it I'm quiet familiar with the check list

 

[JohnS_3CX]

If it works from a different site then you might have

- been blacklisted on that one other site's IP
- port forwards may not be set up right
- SIP ALG may be running on that network and messing up the SIP traffic

 

[Nkosiedread]

If it works from a different site then you might have

- been blacklisted on that one other site's IP
- port forwards may not be set up right
- SIP ALG may be running on that network and messing up the SIP traffic

I have zero black list, I'm suspecting port forwarding.

Is there a way to rule it out or what to look for from the captures if it's a port forwarding or SIP ALG ?

 

[JohnS_3CX]

You can look at the capture generated from the actual phone device itself, and compare it to the one the PBX was capturing at the same time.

The info should match in both captures, so for example if the phone is using port 5065 but the PBX sees it coming from something random then you will know that your port forwards need attention.