NOTICE[36583]: stun.c:247 handle_stun_timeout: Attempt 1 to send STUN request to ‘142.250.25.127’ timed out.
stun.c:247 handle_stun_timeout: Attempt 2 to send STUN request to ‘142.250.25.127’ timed out.
WARNING[36583]: stun.c:252 handle_stun_timeout: Attempt 3 to send STUN request to ‘142.250.25.127’ timed out. Check that the server address is correct and reachable.
NOTICE[36583]: stun.c:247 handle_stun_timeout: Attempt 1 to send STUN request to ‘142.250.25.127’ timed out.
NOTICE[36583]: stun.c:247 handle_stun_timeout: Attempt 2 to send STUN request to ‘142.250.25.127’ timed out.
WARNING[36583]: stun.c:252 handle_stun_timeout: Attempt 3 to send STUN request to ‘142.250.25.127’ timed out. Check that the server address is correct and reachable.
NOTICE[36583]: stun.c:247 handle_stun_timeout: Attempt 1 to send STUN request to ‘142.250.25.127’ timed out.
NOTICE[36583]: stun.c:247 handle_stun_timeout: Attempt 2 to send STUN request to ‘142.250.25.127’ timed out.
WARNING[36583]: stun.c:252 handle_stun_timeout: Attempt 3 to send STUN request to ‘142.250.25.127’ timed out. Check that the server address is correct and reachable.
NOTICE[36583]: stun.c:247 handle_stun_timeout: Attempt 1 to send STUN request to ‘142.250.25.127’ timed out.
NOTICE[36583]: stun.c:247 handle_stun_timeout: Attempt 2 to send STUN request to ‘142.250.25.127’ timed out.
WARNING[36583]: stun.c:252 handle_stun_timeout: Attempt 3 to send STUN request to ‘142.250.25.127’ timed out. Check that the server address is correct and reachable.
stunclient returns binding test success and all the necessary ports are opened in firewall. Still getting the above mentioned error in asterisk.
There is an obvious syntax error.
An issue was opened at [ASTERISK-30434] Asterisk webrtc - Digium/Asterisk JIRA for this by the thread creator.
On the bug report, you say that Asterisk uses a random source port. Surely it should use the same port number as the traffic for which the request was intended, otherwise the public port number returned from the STUN server isn’t of much use, except possibly as a warning that the port number might change in transit.
The particular message above is for discovering the external IP address generally, so the port doesn’t matter.
Of course in the context of WebRTC it can also be used for discovering the server reflexive candidate, in which case the RTP port would be used. There’s not enough details here specifically.
You are assuming there is only one public address in the NAT pool. That is not necessarily true. My router has more than one, although, if I were running Asterisk over it, I wouldn’t be using STUN and would fix the one in use in the router. I suspect you could get this, in a situation you couldn’t control, with some mobile phone networks.
Right, there’s cases where it doesn’t work.
wireshark trace
Frame 2541: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface any, id 0
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.10.10.73, Dst: 18.191.223.12
User Datagram Protocol, Src Port: 18140, Dst Port: 38413
Source Port: 18140
Destination Port: 38413
Length: 28
Checksum: 0x064c [unverified]
[Checksum Status: Unverified]
[Stream index: 25]
[Timestamps]
UDP payload (20 bytes)
Simple Traversal of UDP Through NAT
Message Type: Binding Request (0x0001)
Message Length: 0x0000
Message Transaction ID: c636b446615b4627b008f03a3044621d
A random destination port is used.
Here the destination port is random ie., 38413. It should be 3478 ie., the stun server port for stunserver.stunprotocol.org
while running a s/w named stunclient, it returns success
./stunclient stunserver.stunprotocol.org 3478
Binding test: success
Local address: 10.10.10.73:53056
Mapped address: 14.139.183.221:53056
wireshark trace
Frame 16893: 72 bytes on wire (576 bits), 72 bytes captured (576 bits) on interface any, id 0
Linux cooked capture v1
Internet Protocol Version 4, Src: 10.10.10.73, Dst: 18.191.223.12
User Datagram Protocol, Src Port: 53056, Dst Port: 3478
Source Port: 53056
Destination Port: 3478
Length: 36
Checksum: 0x0654 [unverified]
[Checksum Status: Unverified]
[Stream index: 463]
[Timestamps]
UDP payload (28 bytes)
Session Traversal Utilities for NAT
Here the destination port is 3478. 3478 is opened in my firewall. Thats why I’m getting binding success. But while running in asterisk, a random port is used as the destination port for stun server.
source port 18410 is opened in firewall. Ports 10000-20000 is opened in firewall.
You’re going to need to provide context for the Asterisk log. Were STUN requests being sent? Was a call going on? Do you have res_stun_monitor configured and that is what is doing the STUN request?
stun request is sent. But there is no response from the stun server. stun show status sometimes show the public ip and port. Sometimes it shows as 0
Okay, so this has nothing to do with rtp.conf - res_stun_monitor is a separate module and is separately configured.