> ----- Mail original ----- > De: "David Ponzone" <david.ponz...@gmail.com>
> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans > tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et > faisant le relais RTP. Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn et tout, mais ça marche pas. De même, l'activation infructueuse de nat=yes me laisse très dubitatif. Si Asterisk réécrit les SDP, ça devrait fonctionner, sauf si les softphones sont bind() uniquement sur l'IP RFC1918 locale (non VPN). Je vais revenir sur ça demain. Quand tu parles de relais RTP, tu veux parler de relais SDP, non ? Perso, je ne veux pas qu'Asterisk soit relais RTP, car il faut dimensionner le serveur pour la montée en chargée. C'est aussi pour ça que je n'ai pas installé de serveur TURN, qui serait une solution vite-fait-bien-fait à mon problème. > Je pense qu’il faut explorer cette piste, en prenant des traces côté Asterisk > si nécessaire, et comprendre ce qui merde. Je n'ai pas de capture réseau des essais avec nat=yes, et oui, c'est problématique. > Ca permettrait au moins d’incriminer l’ASA une fois pour toute. Ben ça, j'ai du wireshark sur les clients et du tcpdump sur l'Asterisk donc j'vois bien que la SDP part avec une IP "invalide" d'un softphone, qu'Asterisk la relaie et que le client la reçoit. Et inversement, quand ça marche, je vois des SDP avec la "bonne" IP. Ces captures datent d'avant l'activation de nat=yes sur quelques comptes SIP, bien entendu. Ce qui m'étonne le plus, c'est le softphone qui utilise STUN, puis en fait non, puis qui ne tient plus compte de la réponse STUN pour forger sa SDP, puis si, puis non, puis après il ne tient pas compte d'une SDP valide reçue donc il envoie le flux audio au mauvais endroit, puis ça marche, puis retour case départ… --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
