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.
C'est donc la branche de dev, qui ne devrait normalement pas poser de problèmes de gestion du t38.
Essaye de poster dans FS-users, en décrivant le problème, il est possible que l'on te demande d'ouvrir ou de compléter un ticket existant avec quelques traces SIP et les logs FS correspondantes.
-- DP> http://couic-couic.fr le lien ne marche pas... -+- W in: <http://www.le-gnu.net> - Je lui fais couic-couic -+-
C'est donc la branche de dev, qui ne devrait normalement pas poser de
problèmes de gestion du t38.
Essaye de poster dans FS-users, en décrivant le problème, il est
possible que l'on te demande d'ouvrir ou de compléter un ticket existant
avec quelques traces SIP et les logs FS correspondantes.
--
DP> http://couic-couic.fr
le lien ne marche pas...
-+- W in: <http://www.le-gnu.net> - Je lui fais couic-couic -+-
C'est donc la branche de dev, qui ne devrait normalement pas poser de problèmes de gestion du t38.
Essaye de poster dans FS-users, en décrivant le problème, il est possible que l'on te demande d'ouvrir ou de compléter un ticket existant avec quelques traces SIP et les logs FS correspondantes.
-- DP> http://couic-couic.fr le lien ne marche pas... -+- W in: <http://www.le-gnu.net> - Je lui fais couic-couic -+-
Geo Cherchetout
Le 26/12/2013 22:42, j'ai écrit :
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"/>
J'ai peut-être une explication, quoique pas totalement convaincante : Dans le champ « Allow: » des messages SIP que FreeSwitch émet figure la méthode UPDATE. Résultat, c'est une requête UPDATE que le proxy OVH lui envoie et non une requête INVITE, et il n'est pas impossible que ce soit la raison pour laquelle FreeSwitch répond OK...
Quoi qu'il en soit, surmontant mon appréhension, je me suis finalement tourné vers Asterisk et j'ai bien fait. Avec sa configuration par défaut, Asterisk décline sans hésiter toute INVITE porteuse d'une SDP pour du T.38. (Et la méthode UPDATE ne figure dans aucun des messages qu'émet Asterisk.)
Merci Asterisk. :-)
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.
Je dois signaler que la prochaine version de Linphone (3.7.0 ?) est exempte de ce problème, son développeur principal lui ayant apporté un correctif grâce auquel il sait dire NON quand il le faut. L'interposition d'Asterisk pourrait néanmoins être une solution pour les autres softphones non durcis.
Le 26/12/2013 22:42, j'ai écrit :
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"/>
J'ai peut-être une explication, quoique pas totalement convaincante : Dans
le champ « Allow: » des messages SIP que FreeSwitch émet figure la méthode
UPDATE. Résultat, c'est une requête UPDATE que le proxy OVH lui envoie et
non une requête INVITE, et il n'est pas impossible que ce soit la raison
pour laquelle FreeSwitch répond OK...
Quoi qu'il en soit, surmontant mon appréhension, je me suis finalement
tourné vers Asterisk et j'ai bien fait. Avec sa configuration par défaut,
Asterisk décline sans hésiter toute INVITE porteuse d'une SDP pour du T.38.
(Et la méthode UPDATE ne figure dans aucun des messages qu'émet Asterisk.)
Merci Asterisk. :-)
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.
Je dois signaler que la prochaine version de Linphone (3.7.0 ?) est exempte
de ce problème, son développeur principal lui ayant apporté un correctif
grâce auquel il sait dire NON quand il le faut.
L'interposition d'Asterisk pourrait néanmoins être une solution pour les
autres softphones non durcis.
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"/>
J'ai peut-être une explication, quoique pas totalement convaincante : Dans le champ « Allow: » des messages SIP que FreeSwitch émet figure la méthode UPDATE. Résultat, c'est une requête UPDATE que le proxy OVH lui envoie et non une requête INVITE, et il n'est pas impossible que ce soit la raison pour laquelle FreeSwitch répond OK...
Quoi qu'il en soit, surmontant mon appréhension, je me suis finalement tourné vers Asterisk et j'ai bien fait. Avec sa configuration par défaut, Asterisk décline sans hésiter toute INVITE porteuse d'une SDP pour du T.38. (Et la méthode UPDATE ne figure dans aucun des messages qu'émet Asterisk.)
Merci Asterisk. :-)
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.
Je dois signaler que la prochaine version de Linphone (3.7.0 ?) est exempte de ce problème, son développeur principal lui ayant apporté un correctif grâce auquel il sait dire NON quand il le faut. L'interposition d'Asterisk pourrait néanmoins être une solution pour les autres softphones non durcis.
