Connection Satellite = Pas de son en outbound

Bonjour à tous.

Je rencontre un soucis plutot embêtant ...

J'ai configuré 2 comptes SIP, un pour les appels mobiles easyvoip et un autre pour les fixes chez ovh sur un serveur asterisk.

Le compte easyvoip fonctionne très bien, par contre le compte ovh est plus problèmatique ...

Je peux recevoir des appels mais pas en faire .. en fait lors d'un appel outbound le combiné distant sonne mais je ne l'entend pas dans le combiné appelant .. une fois décroché .. rien dans les deux sens ... le raccroché ne semble pas fonctionner non plus (si je rapelle tout de suite derrière la ligne est occupée) ...

La ou cela devient tordu ... c'est que cela se passe uniquement lors d'une connection par satellite bi-dir (pouvait pas le dire avant lui ^^) et de fait je suis derrière un proxy basé en Italie ...

pour le moment j'ai encore une ligne adsl, si je branche le modem adsl sur le wan de mon routeur suivi d'un refresh dhcp du wan, tout fonctionne .. je remplace le modem adsl par le modem satellite, refresh dhcp wan et pan .. plus d'outbound pour ovh alors que easyvoip fonctionne ....

Autre source de confusion = si j'installe Ekiga sur mon poste windows connecté en satellite et utilise mon compte ovh, ça marche ....

Bref ...

ekiga+sat+ovh = OK
ekiga+adsl+ovh= OK
asterisk+adsl+ovh=OK
asterisk+sat+OVH=KO appels sortants ...

Vous auriez une petite idée à tout hasard ? :whistle:

J'ai peut être une amorce de début d'un morceau d'explication ...

Ekiga utilise Stun .... 3CX PBX Aussi ... et les deux fonctionnent avec ma connection satellitaire cachée derrière un proxy ...

Déduction peut être foireuse mais bon ... alors j'ai beau lire tout ce qui me tombe sous la main concernant STUN .. je n'entrave pas grand chose.

J'ai cru comprendre que dans certaines conditions, cela pouvait aider quand le nat ne peut fonctionner correctement ..

Donc THE question ... Asterisk gère t'il STUN ? :D

stun permet au client stun de découvrir son adresse publique et de la mettre correctement dans les messages sip.

en détail, le SIP prévoit que les flux RTP (audio) soient envoyés aux adresses indiquées dans le protocole sip, ce qui ne fonctionne pas qd le client est natté - il met son @ privée. l'option nat=yes de asterisk lui dit de répondre sur les ports/ip ou ils recoit les paquets, et pas ceux indiqués dans le protocole. alternativement, en envoyant un paquet à stun server, celui ci lui répond simplement depuis quelle @ il a vu arriver le paquet, le client découvre ainsi son @ publique et l'insére ensuite dans le paquets sip

Merci pour la clarification, c'est plus clair maintenant.

Personne n'aurais d'idée quand au fait qu'asterisk ne fonctionne pas dans cette configuration ?

J'ai testé freeswitch, ça fonctionne sans configuration particulière, Yate, pareil.

Mais vu la complexité apparente de la configuration je me suis tourné vers 3CX sous windows .. sauf qu'il ne gère pas la tdm400p de digium et que .. par principe .. je ne vois pas pourquoi ça ne fonctionne pas sous asterisk ..

J'ai testé PIAF,Askozia,Freepbx et un asterisk nu, meme comportement, si on m'apelle de l'extérieur tout fonctionne, si j'apelle de l'intérieur vers l'extérieur sur le trunk OVH, je n'entend pas la sonnerie coté appellant et pas de voix des deux cotés, le raccorché n'est pas pris en compte non plus ...

Je ne vois pas trop par ou commencer, j'ai tout tenté niveau routage mais je ne m'explique pas pourquoi avec tous les autres IPBX cela fonctionne "Out Of Box" et qu'avec Asterisk mon trunk OVH déconne alors que le easyvoip fonctionne ...

Voila, on ne sais jamais, si quelqu'un avait déja rencontré ce problème, j'ai une vm au chaud pour tester toute solution :)

règle externip=IP_Externe dans le sip.conf et effectue un debug SIP sur l'appel sortant sur le trunk ou ça fonctionne, et sur le trunk ou ça ne fonctionne pas, utilise pastebin pour nous montrer les traces.

Je termine ma conf 3CX et je regarde cela..

Par contre, mon ip externe n'est pas pingable, juste le proxy de mon provider sat.

Voici les résultats :sweat:

testé sur une base Askozia - Asterisk 1.8.4.4

Appel OK trunk Easyvoip:
http://pastebin.com/AmCjUPAy

Appel KO trunk Ovh:
http://pastebin.com/cgAWhaxj

Dans les 2 cas, j'appelle à partir d'un sip interne poste 101 le même portable externe à 2 minutes d'intervalle.

Pour isoler tout problème potentiel de règle de sortie, j'ai autorisé les deux pour tout sortant et je n'ai activé que le trunk testé, l'autre est désactivé pendant le test.

Les appels entrants fonctionnent dans les deux cas par contre.

en y repensant, si reellement tu veux t'affranchir de la question 'est ce que ca vient du sat', il faut monter un vpn.

si ca passe sur le vpn over sat, c'est que le reseau sat filtre certains ports / protocoles via dpi, sinon, pbm de latence

Ce qui est sur, c'est que ça vient de la connection sat, car si je met l'adsl à la place, tout fonctionne bien (mais pas viable, ma connection sat est plus fiable que mon adsl ...)

Par contre, cela n'explique pas pourquoi cela ne fonctionne pas sur CE trunk et avec Asterisk alors que les autres ipbx fonctionnent directement ..

frustrant .. d'autant plus que j'ai besoin de ma tdm400p :pt1cable:

pbm de routage chez l'opérateur satellite ?

firewall dans la chaine qui fout le bazar ?

en l'état,, il te faut mettre un wireshark et et regarder la correspondance entre les ports indiqués dans le protocole et ceux utilisés réellement, est ce qu'il y a du rtp, etc...
un rtp debug on envoie vachement sur l'écran, mais tu vois ou asterisk veut envoyer le media

et bien le problème de routage chez l'opérateur j'y crois moyen en tant que tel .. ni le firewall ... plutot un ensemble qui fait que ..

Etant donné que cela ne se produit qu'avec asterisk+sat+ovh ... c'est une belle pagaille .. car dès que l'on remplace un des éléments, les autres fonctionnent ..

pour avoir travaillé chez un FAI... la pagaille est mot assez commun.... la moitié des ingé se foutent sur la gueule avec la moitié des mecs de l'exploit et personne ne comprend rien au routage... nos brillantes equipes ont passé 2 semaines à mettre en service un lien, à cause justement d'un pbm de routage...

De toutes façons il vas falloir que j'analyse plus en profondeur comme tu me l'indiquais malgré mes maigres connaissances ..

Mais pour le moment .. j'attends que mon raid5 fasse son grow avant de relancer ma vm (je précise que ce problème est aussi présent sur du vrai hard hein)