Comment empêcher un paquet UDP particulier de parvenir à Linphone ?
22 réponses
Geo Cherchetout
Bonjour,
Je pense avoir identifié la cause exacte de mes échecs répétés quand je
tente d'envoyer un fax à l'aide de Linphone dans le rôle de transmetteur.
Quand Linphone reçoit une requête INVITE décrivant une session T38, au lieu
de répondre par un message du genre 488 (not acceptable here), il répond OK
et c'est le début d'un dialogue de sourd qui ne prend fin que quand le
télécopieur de mon correspondant décide de raccrocher.
Je précise que ni ce télécopieur ni mon fax-modem ne connaissent le
protocole T38. C'est apparemment la passerelle entre OVH et Orange qui prend
l'initiative malencontreuse de me faire envoyer ce paquet pour une raison
que j'ignore.
Je voudrais donc voir ce qu'il se passerait si le paquet UDP fautif de
trouble était escamoté silencieusement avant de parvenir à Linphone.
Ce paquet est reconnaissable en ce qu'il comporte une fois la chaîne de
caractères t38 et plusieurs fois T38. Je suppose qu'iptables est l'outil
adéquat mais il serait absurde que je passe des jours à apprivoiser cette
usine à gaz si un aimable contributeur pouvait en une minute me donner la
recette. ;-) Merci d'avance à lui ou elle.
Le 14/12/2013 11:43, *Pascal Hambourg* a écrit fort à propos :
Salut,
Geo Cherchetout a écrit :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
C'est un peu large. Par exemple cette règle risque d'empêcher la réception de ce message en bloquant le segment qui contient 't38'. Il faudrait affiner en ajoutant le protocole UDP et les ports 5060:5061, voire l'adresse source de la passerelle SIP.
Oui oui, j'ai eu l'idée, j'ai fait comme suit :
# iptables -A INPUT -p udp --src 91.121.129.20 --dport 5061 -m string --string 't38' --algo bm -j DROP
Mon intention était justement de bloquer ces paquets, ce qui se produit effectivement. J'avais l'espoir que l'émetteur de cette requête intempestive se lasserait très vite de ne pas la voir honorée et que la conversation normale entre fax analogiques pourrait se poursuivre ou reprendre. Mais non, la même requête est réémise 1/2 s plus tard, puis 1 s, puis 2 s, puis 4 s, puis 8 s. (Pendant tout ce temps, les fax ou pseudo-fax s'égosillent à qui mieux mieux sans être entendus.) Enfin, 16,5 secondes après cette dernière, il se résout enfin à envoyer une requête INVITE proposant une session de fax classique, que Linphone reçoit certainement mais trop tard. Linphone vient juste d'envoyer une requête BYE 40 ms auparavant... Quelle aventure ! ;-)
Le 14/12/2013 11:43, *Pascal Hambourg* a écrit fort à propos :
Salut,
Geo Cherchetout a écrit :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
C'est un peu large. Par exemple cette règle risque d'empêcher la
réception de ce message en bloquant le segment qui contient 't38'.
Il faudrait affiner en ajoutant le protocole UDP et les ports 5060:5061,
voire l'adresse source de la passerelle SIP.
Oui oui, j'ai eu l'idée, j'ai fait comme suit :
# iptables -A INPUT -p udp --src 91.121.129.20 --dport 5061 -m string
--string 't38' --algo bm -j DROP
Mon intention était justement de bloquer ces paquets, ce qui se produit
effectivement. J'avais l'espoir que l'émetteur de cette requête intempestive
se lasserait très vite de ne pas la voir honorée et que la conversation
normale entre fax analogiques pourrait se poursuivre ou reprendre. Mais non,
la même requête est réémise 1/2 s plus tard, puis 1 s, puis 2 s, puis 4 s,
puis 8 s. (Pendant tout ce temps, les fax ou pseudo-fax s'égosillent à qui
mieux mieux sans être entendus.) Enfin, 16,5 secondes après cette dernière,
il se résout enfin à envoyer une requête INVITE proposant une session de fax
classique, que Linphone reçoit certainement mais trop tard. Linphone vient
juste d'envoyer une requête BYE 40 ms auparavant...
Quelle aventure ! ;-)
Le 14/12/2013 11:43, *Pascal Hambourg* a écrit fort à propos :
Salut,
Geo Cherchetout a écrit :
# iptables -A INPUT -m string --string 't38' --algo bm -j DROP
C'est un peu large. Par exemple cette règle risque d'empêcher la réception de ce message en bloquant le segment qui contient 't38'. Il faudrait affiner en ajoutant le protocole UDP et les ports 5060:5061, voire l'adresse source de la passerelle SIP.
Oui oui, j'ai eu l'idée, j'ai fait comme suit :
# iptables -A INPUT -p udp --src 91.121.129.20 --dport 5061 -m string --string 't38' --algo bm -j DROP
Mon intention était justement de bloquer ces paquets, ce qui se produit effectivement. J'avais l'espoir que l'émetteur de cette requête intempestive se lasserait très vite de ne pas la voir honorée et que la conversation normale entre fax analogiques pourrait se poursuivre ou reprendre. Mais non, la même requête est réémise 1/2 s plus tard, puis 1 s, puis 2 s, puis 4 s, puis 8 s. (Pendant tout ce temps, les fax ou pseudo-fax s'égosillent à qui mieux mieux sans être entendus.) Enfin, 16,5 secondes après cette dernière, il se résout enfin à envoyer une requête INVITE proposant une session de fax classique, que Linphone reçoit certainement mais trop tard. Linphone vient juste d'envoyer une requête BYE 40 ms auparavant... Quelle aventure ! ;-)
Eric Masson
Geo Cherchetout writes:
'Lut,
Oui oui, j'ai eu l'idée, j'ai fait comme suit :
# iptables -A INPUT -p udp --src 91.121.129.20 --dport 5061 -m string --string 't38' --algo bm -j DROP
Mon intention était justement de bloquer ces paquets, ce qui se produit effectivement. J'avais l'espoir que l'émetteur de cette requête intempestive se lasserait très vite de ne pas la voir honorée et que la conversation normale entre fax analogiques pourrait se poursuivre ou reprendre. Mais non, la même requête est réémise 1/2 s plus tard, puis 1 s, puis 2 s, puis 4 s, puis 8 s. (Pendant tout ce temps, les fax ou pseudo-fax s'égosillent à qui mieux mieux sans être entendus.) Enfin, 16,5 secondes après cette dernière, il se résout enfin à envoyer une requête INVITE proposant une session de fax classique, que Linphone reçoit certainement mais trop tard. Linphone vient juste d'envoyer une requête BYE 40 ms auparavant...
Dans le cas présent le traffic est juste droppé, la solution serait probablement de refuser la négociation T38 à la place du linphone et donc d'implémenter un proxy sur la machine qui fait tourner le netfilter pour le moment.
-- Grace à mail and news de microsoft, ont pouvait faire un del total de tous messages sur tous les news groupes (c'est l'un des bugs du logiciel) fort heureusement personne ne l'a vu ou utiliser. -+- J0 in <http://www.le-gnu.net> : Docteur Follanews -+-
# iptables -A INPUT -p udp --src 91.121.129.20 --dport 5061 -m string
--string 't38' --algo bm -j DROP
Mon intention était justement de bloquer ces paquets, ce qui se produit
effectivement. J'avais l'espoir que l'émetteur de cette requête
intempestive se lasserait très vite de ne pas la voir honorée et que la
conversation normale entre fax analogiques pourrait se poursuivre ou
reprendre. Mais non, la même requête est réémise 1/2 s plus tard, puis 1
s, puis 2 s, puis 4 s, puis 8 s. (Pendant tout ce temps, les fax ou
pseudo-fax s'égosillent à qui mieux mieux sans être entendus.) Enfin,
16,5 secondes après cette dernière, il se résout enfin à envoyer une
requête INVITE proposant une session de fax classique, que Linphone
reçoit certainement mais trop tard. Linphone vient juste d'envoyer une
requête BYE 40 ms auparavant...
Dans le cas présent le traffic est juste droppé, la solution serait
probablement de refuser la négociation T38 à la place du linphone et
donc d'implémenter un proxy sur la machine qui fait tourner le netfilter
pour le moment.
--
Grace à mail and news de microsoft, ont pouvait faire un del total de
tous messages sur tous les news groupes (c'est l'un des bugs du
logiciel) fort heureusement personne ne l'a vu ou utiliser.
-+- J0 in <http://www.le-gnu.net> : Docteur Follanews -+-
# iptables -A INPUT -p udp --src 91.121.129.20 --dport 5061 -m string --string 't38' --algo bm -j DROP
Mon intention était justement de bloquer ces paquets, ce qui se produit effectivement. J'avais l'espoir que l'émetteur de cette requête intempestive se lasserait très vite de ne pas la voir honorée et que la conversation normale entre fax analogiques pourrait se poursuivre ou reprendre. Mais non, la même requête est réémise 1/2 s plus tard, puis 1 s, puis 2 s, puis 4 s, puis 8 s. (Pendant tout ce temps, les fax ou pseudo-fax s'égosillent à qui mieux mieux sans être entendus.) Enfin, 16,5 secondes après cette dernière, il se résout enfin à envoyer une requête INVITE proposant une session de fax classique, que Linphone reçoit certainement mais trop tard. Linphone vient juste d'envoyer une requête BYE 40 ms auparavant...
Dans le cas présent le traffic est juste droppé, la solution serait probablement de refuser la négociation T38 à la place du linphone et donc d'implémenter un proxy sur la machine qui fait tourner le netfilter pour le moment.
-- Grace à mail and news de microsoft, ont pouvait faire un del total de tous messages sur tous les news groupes (c'est l'un des bugs du logiciel) fort heureusement personne ne l'a vu ou utiliser. -+- J0 in <http://www.le-gnu.net> : Docteur Follanews -+-
Geo Cherchetout
Le 14/12/2013 14:10, *Eric Masson* a écrit fort à propos :
Dans le cas présent le traffic est juste droppé, la solution serait probablement de refuser la négociation T38 à la place du linphone et donc d'implémenter un proxy sur la machine qui fait tourner le netfilter pour le moment.
Merci, l'idée me plaît beaucoup mais je ne suis pas sûr d'être capable de la mettre en application. Je vais y réfléchir. Freeswitch ?
Le 14/12/2013 14:10, *Eric Masson* a écrit fort à propos :
Dans le cas présent le traffic est juste droppé, la solution serait
probablement de refuser la négociation T38 à la place du linphone et
donc d'implémenter un proxy sur la machine qui fait tourner le netfilter
pour le moment.
Merci, l'idée me plaît beaucoup mais je ne suis pas sûr d'être capable de la
mettre en application. Je vais y réfléchir. Freeswitch ?
Le 14/12/2013 14:10, *Eric Masson* a écrit fort à propos :
Dans le cas présent le traffic est juste droppé, la solution serait probablement de refuser la négociation T38 à la place du linphone et donc d'implémenter un proxy sur la machine qui fait tourner le netfilter pour le moment.
Merci, l'idée me plaît beaucoup mais je ne suis pas sûr d'être capable de la mettre en application. Je vais y réfléchir. Freeswitch ?
Eric Masson
Geo Cherchetout writes:
'Re,
Merci, l'idée me plaît beaucoup mais je ne suis pas sûr d'être capable de la mettre en application. Je vais y réfléchir. Freeswitch ?
Il semble que FS dispose de la possibilité de refuser une négociation t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864, l'intervention d'A. Minessale le 23/11/2010 à 16h34.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
-- je suis équipé d'un PC avec PENTIUM II 300 mhz, et d'une RAM de 64 Mo, modem USR de 58 K Pour améliorer les perfo sur Internet, vaut-il mieux accroître la RAM ou faire passer le P II à 450 Mhz ? -+- PL in GNU : Bien configurer son Cray T3E avec Wanadoo -+-
Merci, l'idée me plaît beaucoup mais je ne suis pas sûr d'être capable
de la mettre en application. Je vais y réfléchir. Freeswitch ?
Il semble que FS dispose de la possibilité de refuser une négociation
t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864,
l'intervention d'A. Minessale le 23/11/2010 à 16h34.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
--
je suis équipé d'un PC avec PENTIUM II 300 mhz, et d'une RAM de 64 Mo,
modem USR de 58 K Pour améliorer les perfo sur Internet, vaut-il mieux
accroître la RAM ou faire passer le P II à 450 Mhz ?
-+- PL in GNU : Bien configurer son Cray T3E avec Wanadoo -+-
Merci, l'idée me plaît beaucoup mais je ne suis pas sûr d'être capable de la mettre en application. Je vais y réfléchir. Freeswitch ?
Il semble que FS dispose de la possibilité de refuser une négociation t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864, l'intervention d'A. Minessale le 23/11/2010 à 16h34.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
-- je suis équipé d'un PC avec PENTIUM II 300 mhz, et d'une RAM de 64 Mo, modem USR de 58 K Pour améliorer les perfo sur Internet, vaut-il mieux accroître la RAM ou faire passer le P II à 450 Mhz ? -+- PL in GNU : Bien configurer son Cray T3E avec Wanadoo -+-
Geo Cherchetout
Le 14/12/2013 17:30, *Eric Masson* a écrit fort à propos :
Il semble que FS dispose de la possibilité de refuser une négociation t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864, l'intervention d'A. Minessale le 23/11/2010 à 16h34.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
J'ai donc installé FreeSwitch sur un autre ordinateur de mon réseau local. Mon Linphone s'enregistre auprès de FreeSwitch et FreeSwitch s'enregistre auprès d'OVH. Linphone parvient à établir des communications avec le réseau téléphonique commuté mais la plupart des paquets UDP, dont les fameuses requêtes indésirables, arrivent à Linphone et partent de Linphone sans passer par l'intermédiaire de FreeSwitch. :-( Dans ces conditions, je crains que le conseil d'Anthony ne serve pas à grand chose. Quelle grossière erreur ai-je fait ? Un indice peut-être : Pour appeler quelqu'un, je dois, comme auparavant, composer <sip: car ce qui m'aurait semblé logique ne marche pas : <sip:
Le 14/12/2013 17:30, *Eric Masson* a écrit fort à propos :
Il semble que FS dispose de la possibilité de refuser une négociation
t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864,
l'intervention d'A. Minessale le 23/11/2010 à 16h34.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
J'ai donc installé FreeSwitch sur un autre ordinateur de mon réseau local.
Mon Linphone s'enregistre auprès de FreeSwitch et FreeSwitch s'enregistre
auprès d'OVH. Linphone parvient à établir des communications avec le réseau
téléphonique commuté mais la plupart des paquets UDP, dont les fameuses
requêtes indésirables, arrivent à Linphone et partent de Linphone sans
passer par l'intermédiaire de FreeSwitch. :-( Dans ces conditions, je crains
que le conseil d'Anthony ne serve pas à grand chose.
Quelle grossière erreur ai-je fait ?
Un indice peut-être :
Pour appeler quelqu'un, je dois, comme auparavant, composer
<sip:EZABPQMCDU@sip.ovh.fr> car ce qui m'aurait semblé logique ne marche pas
: <sip:EZABPQMCDU@IP.Ordi.Free.Switch>
Le 14/12/2013 17:30, *Eric Masson* a écrit fort à propos :
Il semble que FS dispose de la possibilité de refuser une négociation t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864, l'intervention d'A. Minessale le 23/11/2010 à 16h34.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
J'ai donc installé FreeSwitch sur un autre ordinateur de mon réseau local. Mon Linphone s'enregistre auprès de FreeSwitch et FreeSwitch s'enregistre auprès d'OVH. Linphone parvient à établir des communications avec le réseau téléphonique commuté mais la plupart des paquets UDP, dont les fameuses requêtes indésirables, arrivent à Linphone et partent de Linphone sans passer par l'intermédiaire de FreeSwitch. :-( Dans ces conditions, je crains que le conseil d'Anthony ne serve pas à grand chose. Quelle grossière erreur ai-je fait ? Un indice peut-être : Pour appeler quelqu'un, je dois, comme auparavant, composer <sip: car ce qui m'aurait semblé logique ne marche pas : <sip:
Geo Cherchetout
Le 14/12/2013 17:30, *Eric Masson* a écrit dans fcolc :
Il semble que FS dispose de la possibilité de refuser une négociation t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864, l'intervention d'A. Minessale le 23/11/2010 à 16h34.
Hélas, tout comme linphone, FS répond OK dès que la première requête pour du t38 en provenance d'OVH se présente. J'ai pourtant fait comme indiqué par le plus qualifié des experts en insérant dans /usr/local/freeswitch/conf/vars.xml cette ligne :
<X-PRE-PROCESS cmd="set" data="refuse_t38=true"/>
Sans trop savoir si c'est bien le bon endroit, j'ai aussi ajouté une dernière ligne à mon fichier /usr/local/freeswitch/conf/sip_profiles/external/sip.ovh.fr.xml :
Pour ceux qui ne fréquentent pas fcolc, mon objectif est d'envoyer des télécopies en utilisant Linphone dans le rôle d'ATA, ce qui échoue en raison d'une initiative de mon opérateur OVH qui, dès qu'il reconnaît dans les signaux audio échangés les tonalités caractéristiques du fax, prétend initier une session au standard T.38. Contrairement à certains autres softphones, dont Ekiga, Linphone ne sait pas décliner une telle INVITE et répond OK, ce qui rend la suite du dialogue, et donc l'envoi de télécopie, impossibles. J'ai installé et intercalé FreeSwitch entre Linphone et OVH dans le seul but de décliner ces requêtes fauteuses de trouble.
Merci de faire profiter de vos lumières un pauvre ignorant. Je positionne le suivi dans fr.comp.reseaux.ip.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
J'ai aussi installé Asterisk et je poserai peut-être aussi une question à propos d'une utilisation possible de SIPProxy pour transformer en réponse correcte la réponse erronée de Linphone...
Le 14/12/2013 17:30, *Eric Masson* a écrit dans fcolc :
Il semble que FS dispose de la possibilité de refuser une négociation
t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864,
l'intervention d'A. Minessale le 23/11/2010 à 16h34.
Hélas, tout comme linphone, FS répond OK dès que la première requête pour du
t38 en provenance d'OVH se présente. J'ai pourtant fait comme indiqué par
le plus qualifié des experts en insérant dans
/usr/local/freeswitch/conf/vars.xml cette ligne :
<X-PRE-PROCESS cmd="set" data="refuse_t38=true"/>
Sans trop savoir si c'est bien le bon endroit, j'ai aussi ajouté une
dernière ligne à mon fichier
/usr/local/freeswitch/conf/sip_profiles/external/sip.ovh.fr.xml :
Pour ceux qui ne fréquentent pas fcolc, mon objectif est d'envoyer des
télécopies en utilisant Linphone dans le rôle d'ATA, ce qui échoue en raison
d'une initiative de mon opérateur OVH qui, dès qu'il reconnaît dans les
signaux audio échangés les tonalités caractéristiques du fax, prétend
initier une session au standard T.38. Contrairement à certains autres
softphones, dont Ekiga, Linphone ne sait pas décliner une telle INVITE et
répond OK, ce qui rend la suite du dialogue, et donc l'envoi de télécopie,
impossibles. J'ai installé et intercalé FreeSwitch entre Linphone et OVH
dans le seul but de décliner ces requêtes fauteuses de trouble.
Merci de faire profiter de vos lumières un pauvre ignorant. Je positionne le
suivi dans fr.comp.reseaux.ip.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
J'ai aussi installé Asterisk et je poserai peut-être aussi une question à
propos d'une utilisation possible de SIPProxy pour transformer en réponse
correcte la réponse erronée de Linphone...
Le 14/12/2013 17:30, *Eric Masson* a écrit dans fcolc :
Il semble que FS dispose de la possibilité de refuser une négociation t38, en effet.
Voir dans ce ticket de bug http://jira.freeswitch.org/browse/FS-2864, l'intervention d'A. Minessale le 23/11/2010 à 16h34.
Hélas, tout comme linphone, FS répond OK dès que la première requête pour du t38 en provenance d'OVH se présente. J'ai pourtant fait comme indiqué par le plus qualifié des experts en insérant dans /usr/local/freeswitch/conf/vars.xml cette ligne :
<X-PRE-PROCESS cmd="set" data="refuse_t38=true"/>
Sans trop savoir si c'est bien le bon endroit, j'ai aussi ajouté une dernière ligne à mon fichier /usr/local/freeswitch/conf/sip_profiles/external/sip.ovh.fr.xml :
Pour ceux qui ne fréquentent pas fcolc, mon objectif est d'envoyer des télécopies en utilisant Linphone dans le rôle d'ATA, ce qui échoue en raison d'une initiative de mon opérateur OVH qui, dès qu'il reconnaît dans les signaux audio échangés les tonalités caractéristiques du fax, prétend initier une session au standard T.38. Contrairement à certains autres softphones, dont Ekiga, Linphone ne sait pas décliner une telle INVITE et répond OK, ce qui rend la suite du dialogue, et donc l'envoi de télécopie, impossibles. J'ai installé et intercalé FreeSwitch entre Linphone et OVH dans le seul but de décliner ces requêtes fauteuses de trouble.
Merci de faire profiter de vos lumières un pauvre ignorant. Je positionne le suivi dans fr.comp.reseaux.ip.
D'autres softwitches doivent aussi disposer de cette fonctionnalité.
J'ai aussi installé Asterisk et je poserai peut-être aussi une question à propos d'une utilisation possible de SIPProxy pour transformer en réponse correcte la réponse erronée de Linphone...
Eric Masson
Geo Cherchetout writes:
'Lut,
Merci de faire profiter de vos lumières un pauvre ignorant. Je positionne le suivi dans fr.comp.reseaux.ip.
Ça vaudrait sûrement le coût de poster dans FS-users (accessible via GMane) sur le sujet, la gestion de t38 ne semble pas avoir de docs définitives (il y a des références au t38 dans sofia et dans spandsp), donc un exposé clair devrait t'amener quelques réponses instructives.
-- Nouveau possesseur d'une paire de Roces Amsterdam je désirerai me mettre au roller...ben..j'sais pas en faire.. alors je voulais savoir si il existait des cours sur Internet ! -+- Spawn in : <http://www.le-gnu.net> - Allez, rouillez jeunesse -+-
Merci de faire profiter de vos lumières un pauvre ignorant. Je
positionne le suivi dans fr.comp.reseaux.ip.
Ça vaudrait sûrement le coût de poster dans FS-users (accessible via
GMane) sur le sujet, la gestion de t38 ne semble pas avoir de docs
définitives (il y a des références au t38 dans sofia et dans spandsp),
donc un exposé clair devrait t'amener quelques réponses instructives.
--
Nouveau possesseur d'une paire de Roces Amsterdam je désirerai me mettre
au roller...ben..j'sais pas en faire.. alors je voulais savoir si il
existait des cours sur Internet !
-+- Spawn in : <http://www.le-gnu.net> - Allez, rouillez jeunesse -+-
Merci de faire profiter de vos lumières un pauvre ignorant. Je positionne le suivi dans fr.comp.reseaux.ip.
Ça vaudrait sûrement le coût de poster dans FS-users (accessible via GMane) sur le sujet, la gestion de t38 ne semble pas avoir de docs définitives (il y a des références au t38 dans sofia et dans spandsp), donc un exposé clair devrait t'amener quelques réponses instructives.
-- Nouveau possesseur d'une paire de Roces Amsterdam je désirerai me mettre au roller...ben..j'sais pas en faire.. alors je voulais savoir si il existait des cours sur Internet ! -+- Spawn in : <http://www.le-gnu.net> - Allez, rouillez jeunesse -+-
Eric Masson
Geo Cherchetout writes:
'Re,
Hélas, tout comme linphone, FS répond OK dès que la première requête pour du t38 en provenance d'OVH se présente. J'ai pourtant fait comme indiqué par le plus qualifié des experts en insérant dans /usr/local/freeswitch/conf/vars.xml cette ligne :
<X-PRE-PROCESS cmd="set" data="refuse_t38=true"/>
C'est logiquement ce qu'il faut faire pour que la négociation t38 soit refusée (réponse 488 au pair) et qu'une négociation sur un codec audio soit reprise.
Quelle est la version de FS installée ?
-- le seul moyen pour ne pas etre "rattrapé" par des aneries qu'on a dites c'est de ne pas dire d'anerie ce qui au bout du compte serait tout bénef pour usenet, mais ce média perdrait alors beaucoup de son attrait -+- JFP in <http://www.le-gnu.net> - L'âne à Lise -
Hélas, tout comme linphone, FS répond OK dès que la première requête
pour du t38 en provenance d'OVH se présente. J'ai pourtant fait comme
indiqué par le plus qualifié des experts en insérant dans
/usr/local/freeswitch/conf/vars.xml cette ligne :
<X-PRE-PROCESS cmd="set" data="refuse_t38=true"/>
C'est logiquement ce qu'il faut faire pour que la négociation t38 soit
refusée (réponse 488 au pair) et qu'une négociation sur un codec audio
soit reprise.
Quelle est la version de FS installée ?
--
le seul moyen pour ne pas etre "rattrapé" par des aneries qu'on a dites
c'est de ne pas dire d'anerie ce qui au bout du compte serait tout
bénef pour usenet, mais ce média perdrait alors beaucoup de son attrait
-+- JFP in <http://www.le-gnu.net> - L'âne à Lise -
Hélas, tout comme linphone, FS répond OK dès que la première requête pour du t38 en provenance d'OVH se présente. J'ai pourtant fait comme indiqué par le plus qualifié des experts en insérant dans /usr/local/freeswitch/conf/vars.xml cette ligne :
<X-PRE-PROCESS cmd="set" data="refuse_t38=true"/>
C'est logiquement ce qu'il faut faire pour que la négociation t38 soit refusée (réponse 488 au pair) et qu'une négociation sur un codec audio soit reprise.
Quelle est la version de FS installée ?
-- le seul moyen pour ne pas etre "rattrapé" par des aneries qu'on a dites c'est de ne pas dire d'anerie ce qui au bout du compte serait tout bénef pour usenet, mais ce média perdrait alors beaucoup de son attrait -+- JFP in <http://www.le-gnu.net> - L'âne à Lise -
Geo Cherchetout
Le 26/12/2013 23:29, *Eric Masson* a écrit fort à propos :
Le 26/12/2013 23:14, *Eric Masson* a écrit fort à propos :
Ça vaudrait sûrement le coût de poster dans FS-users (accessible via GMane) sur le sujet, la gestion de t38 ne semble pas avoir de docs définitives (il y a des références au t38 dans sofia et dans spandsp), donc un exposé clair devrait t'amener quelques réponses instructives.
OK, merci pour la suggestion, le temps de m'abonner et de sortir mon dictionnaire d'anglais et je lance mon SOS.
Le 26/12/2013 23:14, *Eric Masson* a écrit fort à propos :
Ça vaudrait sûrement le coût de poster dans FS-users (accessible via
GMane) sur le sujet, la gestion de t38 ne semble pas avoir de docs
définitives (il y a des références au t38 dans sofia et dans spandsp),
donc un exposé clair devrait t'amener quelques réponses instructives.
OK, merci pour la suggestion, le temps de m'abonner et de sortir mon
dictionnaire d'anglais et je lance mon SOS.
Le 26/12/2013 23:14, *Eric Masson* a écrit fort à propos :
Ça vaudrait sûrement le coût de poster dans FS-users (accessible via GMane) sur le sujet, la gestion de t38 ne semble pas avoir de docs définitives (il y a des références au t38 dans sofia et dans spandsp), donc un exposé clair devrait t'amener quelques réponses instructives.
OK, merci pour la suggestion, le temps de m'abonner et de sortir mon dictionnaire d'anglais et je lance mon SOS.
