Problème de configuration RTP

[mamas]

j'ai bien compris vos questions, mais de mon expérience, il n'est pas nécéssaire pour le client de régler son firewall, s'il autorise le trafic sortant de manière générique.

lors de l'établissement de la comm, s'échangent via les messages INVITE les adresses IP et ports sur lesquels communiquer. le client enovie des paquets, depuis client:port vers asterisk:5060 => le firewall ouvre le port en entrant pour la réponse. pareillement, et sans attendre que les paquets clients arrivent, asterisk envoie des paquets vers le client, depuis l'@ asterisk:port vers client:port - le firewall est censé les laisser passer.

j'ai plusieurs dizaines de clients connectés de cette façon, et je n'ai jamais touché un firewall client (sauf quand ils bloquent l'entrée ET la sortie).

C'est aussi applicable au port 5060. Il n'est même pas garanti que le client utilise ce port comme port source, et il n'est pas nécessaire de l'ouvrir coté client. Il est obligatoire coté serveur.

donc, ma réponse est : plutôt que de monter une usine à gaz, cherchez ce qui ne va pas dans votre config, et vous aurez, de mon expérience, plus à toucher au firewall de vos clients

Après lecture de votre message, me permettez-vous que je vous envoie en message privé la configuration de mon firewall IPTABLES au format TXT ?

[jean]

Je suis un fervent croyant dans les forums... et le fait de poster publquement permettra d'aider qqun d'autre (peut être même pour un soucis qui n'a rien à voir !)

Je préférerais que le contenu soit anonymisé et posté sur le forum.

Pour ce pbm de rtp, que regarder ?

1/ faire un rtp set debug on
(il ne faut pas qu'il y ait trop de trafic, notamment d'autres appels, sinon c'est illisible)
taper la commande sans la valider: rtp set debug off

dans une autre fenetre, avec le package ngrep (installé par apt-get pr debian ou google ngrep sur centos), faire un ngrep -O monfichier.pcap port 5060 and host x.y.z.t
w.y.z.t étant l'ip du client

revenir sur l'autre fenêtre
lancer l'appel
une fois que l'écran de la console ast* defile à fond, on peut faire entree pour arrêter le debug

2/ que regarder ?
- sur le rtp debug, asterisk doit dire qu'il a envoyé des paquets à telle adresse, et reçu des paquets - s'il a pas reçu, effectivement, pbm dans le sens client / serveur
- analyser les trames en copiant le fichier.pcap sur une machine avec wireshark, et regarder les adresses dans l'invite (il indique l'@ du media) - est ce de l'ip publique, ou du lan ?
- vérifier les couples ip destinations / port

3/ si ca ne suffit pas, il faut aussi regarder les trames coté client (un pc windows avec un softphone et un wireshark le permet) et voir à quelle adresse est effectivement envoyé les trames rtp


voila, avec l'ensemble de ces infos, ca permet normalement de voir ce qui ne va pas !