Explications fonctionnement turn

Français
1

Bonjour,

Je reviens vers vous pour m’aider à comprendre le fonctionnement de Turn.

En effet j’essaye de faire fonctionner coturn avec des clients à travers un NAT (softphone) et d’autres qui ne le sont pas (terminaux fixes) .
Coturn semble bien faire le lien entre le client et le serveur, mais j’ai 2 symptomes

  • je n’a pas toujours la voix dans les 2 sens ou la voix tout court
  • parfois j’ai un peu de délai pour l’établissement du peu de voix qu il y a

En terme de principe :

  • je vois dans les SDP que j’ai bien en condidate l’adresse IP du serveur wazo
  • dans le chemin, il voit bien en relay l’adresse du NAT

Néanmoins j’ai un peu de mal à comprendre la logique.
A confirmer mais sur le principe:

  • le client via https fait la negocation avec le serveur wazo distant à travers le nat
    le SDP prend la candidate du serveur wazo
[2025-01-31 19:37:05.6321] a=ice-ufrag:28d7cc82454d547853d61dc8466b4409
[2025-01-31 19:37:05.6321] a=ice-pwd:4bac611a432145ee65fc616b55ebc08b
[2025-01-31 19:37:05.6321] a=candidate:H2148d001 1 UDP 2130706431 adresseipwazo 14408 typ host
[2025-01-31 19:37:05.6321] a=rtpmap:109 opus/48000/2
[2025-01-31 19:37:05.6321] a=fmtp:109 useinbandfec=1
[2025-01-31 19:37:05.6321] a=rtpmap:9 G722/8000
  • en fonction du sens de l’appel (poste fixe vers softphone) j’ai plus d’indication:
[2025-01-31 19:58:39.3153] c=IN IP4 192.168.1.202
[2025-01-31 19:58:39.3153] a=candidate:0 1 UDP 2122252543 192.168.56.1 63207 typ host
[2025-01-31 19:58:39.3153] a=candidate:1 1 UDP 2122187007 2a01:e0a:4bf:d710:e10d:c750:21a1:699 63208 typ host
[2025-01-31 19:58:39.3153] a=candidate:2 1 UDP 2122121471 192.168.1.159 63209 typ host
[2025-01-31 19:58:39.3153] a=candidate:3 1 TCP 2105524479 192.168.56.1 9 typ host tcptype active
[2025-01-31 19:58:39.3153] a=candidate:5 1 TCP 2105458943 2a01:e0a:4bf:d710:e10d:c750:21a1:699 9 typ host tcptype active
[2025-01-31 19:58:39.3153] a=candidate:6 1 TCP 2105393407 192.168.1.159 9 typ host tcptype active
[2025-01-31 19:58:39.3153] a=candidate:7 1 UDP 8200191 192.168.1.202 18889 typ relay raddr 192.168.1.202 rport 18889
[2025-01-31 19:58:39.3153] a=sendrecv
[2025-01-31 19:58:39.3153] a=end-of-candidates

sachant que le 1.159 est l’adresse de mon client et le 1.202 est l’adresse de mon NAT

au final j’ai un peu de mail à comprendre d’ou vient mon problème : je suppose que c’est un problème de turn et non de firewall mais sans certitude

merci à vous

2

sur le softphone, il te faut connecter ton iceServer.

tu dois avoir un paramètre turn / stun dans ton client softphone.

Voilà les notes que j’ai à ce sujet, je ne sais pas si ça va t’aider:

Hello, please be careful, many people doesn’t really understand the ICE (stun/turn).

There is different part for that.

1/ you need to understand that ICE is here to help webrtc with NAT,

it’s like a magical system for the end user to don’t care about NAT configuration.

2/ ICE use turn/stun to help, stun is for signalisation and turn add media.

Please check doc on internet if you don’t understand turn/stun.

3/ For wazo there is different configuration, a. asterisk configuration,

if you want to use turn or stun for your Asterisk because of NAT you can use it,

but if you use webrtc, you need to enable ICE and add turn ou stun service or add the mapping for the ice candidate.

The API support the both.

4/ You need to add in your client the ICE configuration with a STUN or TURN service,

be careful TURN is in general not really mandatory for web/desktop application because the nat network is not really complicated and it’s type 2.

For a mobile application it’s in general more restrictif and you need to use a TURN server

The RTP configuration, including ICE, for Asterisk depends on the global settings defined for Asterisk.

ICE configuration for end users can vary based on your specific logic, such as being configured by tenant.

There are no strict constraints on how ICE is implemented.

For STUN, media does not pass through the server.

For TURN, the media is handled by the service itself.

In both cases, media, including RTP for both video and audio, is managed and transmitted via RTP

3

Et la doc de Wazo.io

cheers

4

Hello Julien

=> je confirme je suis en plein dans le many people :slight_smile:

Oui j’ai bien la config du turn dans le client pas de soucis. Le pire c’est que je vois bien le serveur coturn faire le boulot (ou du moins cela semble) sans erreur particulière

J’ai vu effectivement la doc sur le site wazo.
Néanmoins j’ai du mal à comprendre un point précis:

Si l’adresse candidate est l’adresse ip du wazo (ce qui somme toute est assez logique), comment le client sait qu’il doit passer par le NAT et le turn pour le rejoindre
Car dans les candidats que je vois je ne vois que serveur wazo, ca ok
mais candidat relay, que je ne vois pas toujours dans les trames selon le sens de l’appel, cela donne uniquement l’adresse du NAT…donc indirectement du coturn.

5

Bonjour

Plus précisement c’est ce type de résultat que je comprend pas:

image
image1821×156 41.4 KB

Dans :
softphone vers poste fixe , c’est ok
de poste fixe vers softphone, j’ai le résultat montré qui forcément ne fonctionne pas

Clairement le route nommée n’est pas celle ou l’état ICE est validée, donc cela fonctionne pas…

Pour info, le “inprogress” reste dans cet état

merci

6

c’est bon je viens de trouver
il “suffit” de ne pas intégrer le paramètre “external-ip” dans coturn…étonnant car le serveur est derrière un NAT…

merci

7

Bien vu !

Je trouve que la partie SBC et Turn/stun est complexe et incomprise, surtout qu’on ne pense pas forcément que ça devienne rapidement obligatoire à mettre en place.

Et côté open source, wazo semble avoir arrêté ce projet:

tout est en archive public.

Il y a le projet wazo-edge, qui a reprit la suite, mais qui n’est pas open-source.
Je ne me souviens pas avoir trouvé un “guide” ou une documentation qui explique comment mettre ce type de solution en place.

Si jamais tu souhaites partager ton expérience, ça serait un plus pour les prochains.

En faite, avec wazo-platform, il faut:

  • un pro d’asterisk
  • un dev front
  • un dev backend (plugins ou services annexes)
  • un ingénieur architecte pour l’infra

et les documentations se font toujours aussi rare.

j’avais une doc orienté dev

Mais elle va “disparaitre”, au profit d’une doc un peu différente, qui est en cours:

A terme, cette nouvelle doc devrait permettre l’aide au dev et à l’installation/configuration de l’infrastructure, en plus de répondre à l’administration simple et quotidienne d’un serveur Wazo-platform.

Cheers !

8

Xivo a du edge, c est un ensemble composé de kamalio, coturn et un reverse proxy (nginx)

Je suppose que le produit wazo edge doit être proche

Pour l instant j ai la couche nginx et coturn, turn reste encore a bien stabiliser, car dans mon architecte cible il semble avoir encore un problème qu il me faut etudier

Je me pencherai sur la couche restante, le proxy sip donc kamalio ultérieurement

Mais oui je te rejoins, l installation d une solution complète nécessite beaucoup de compétences.