Hi Jcolp, I apologize for not having responded more, but I was doing further tests. I have a question to ask, following is the whole scenario.
We have an Asterisk server v. 13.10 , it has been installed on the application server LAN, behind DMZ lan. All the incoming traffic is open for WS-Socket and UDP traffic on the following port: 10000-20000 , so a direct nat ip has been assigned to this server with all the incoming traffic open.
We have then clients each of them connected with a dedicated/unique Ip , and they can see asterisk server through a NAT/PAT IP, but the relevant port forwarding listed before is allowed.
Our requirements is to manage conf call, between multiple client that joins to the same rooms.
We have analyzed the traffic between client and server, and the initial connection done from the client to the server is successfully done, while the Audio Streaming through RTSP packets is not audible by the client.
Do you have any suggestion about the network configuration that is missing?
Do you know if Asterisk during the audio streaming initiate a connection vs the client? Or simply publish the audio streaming of the call on a dedicated port and then it is responsability of the client to connect on the relevant port?
We cannot fully understand the way of works of Asterisk server, any information or support would be very appreciated.
This isn’t the really Asterisk works but the way WebRTC itself works. I highly suggest you learn about WebRTC in greater detail if you are doing an actual deployment, as issues like this can and do occur. WebRTC is not something you can just have work all the time as there are too many conditions in play as you’ve seen.
As for how it works all the audio traffic is done using UDP, there is no connection. It starts out negotiating ICE which sends packets between each side on all of their IP addresses to find a path to communicate. If they can’t find a path then you get no media. The candidate lines in the SDP are all of the addresses that the client can accept packets on.
If Asterisk does not present a public IP address as a candidate then the chances of finding a path are lessened.
No, the media path for WebRTC is negotiated using ICE like I mentioned. You can’t force it. Asterisk will switch if ICE negotiation completes to a path that works.
Yes, or STUN. The more routable IP addresses that exist as candidates the better chances of having it work. If it doesn’t work then you have to look at the ICE negotiation - where traffic is going - to better understand why it is failing.
i’m again here Yesterday, we installed an our stun server on the asterisk machine. But when client try to communicate with it, we received this error
received on A1:P1
Got a request (len=60) from 172.18.41.236:65097
Received stun message: 60 bytes
Unknown attribute: 32815
claims attribute is larger than size of message (attribute type=0)
Request did not parse
Failed to parse message
Hello jcolp,
i’m entering the thread, since we are trying to address the issue together.
What do you mean by “it could be a different version of STUN”? actually we installed only ONE stun server where the applications connect. Do you mean there is an expected version to be used?
There are two STUN versions defined. If a client tries to speak the newer version and your STUN server only speaks the old one… it could cause the error that you are seeing. As I have no experience with either the STUN server you’re using or the client you’re using that’s merely a guess based on the log information you have provided.
Hello jcolp,
thanks for the observation. It was very useful. In fact we solved by installing a new STUN server on the same asterisk machine and starting it with the following command: ./stunserver --primaryinterface machine-ip-address --primaryport the-configured-port
This allowed our ICE client (invoked through the web browser) to properly contact the STUN and the communication was perfectly addressed.
Now the problem is related to the network configuration that we cannot change.
Do you see a way to allow the VOIP communication using TCP protocol? I know the audio quality could be low.
how can we do it? googling it seems that RTP is only over UDP.
Thanks
Yesterday, we installed an our stun server on the asterisk machine. But when client try to communicate with it, we received this error