Fréquence décalée

Le 15/02/2013 09:50, *JKB* a écrit fort à propos, quoique pas dans le bon
groupe :

Comment expliquer ce décalage ?

Par le codec. Hors abonnements dits professionnels, les codecs VoIP sont
moisis. C'est entre autre ce qui explique que les fax ne passent pas. Ma
VoIP utilise un codec à 64 kbps (contre 8 à 16 pour la majorité des cas)
et je n'observe pas ce genre de chose.

J'aurais dû le préciser, mon modem est configuré pour utiliser exclusivement
le codec G.711a, qui se trouve être également le codec à 64 kbps du rtc
français. Mais j'ignore si, en cours de route, il n'y a pas quelque part
désencodage et réencodage.
Si tu n'observes pas ce genre de chose avec le même codec, alors tu peux
envoyer et recevoir des fax ? C'est justement ce souci avec les fax que je
cherche à comprendre, et je souhaiterais une explication plus détaillée...

(Je n'ignore pas l'existence du protocole T.38 pour le Fax over IP, mais ce
n'est pas l'objet de la discussion.)

Fu2 et suivi sur fr.reseaux.telecoms.techniques svp

Le 14/02/2013 23:28, geo cherchetout a écrit :

Bonjour,

Je suis abonné chez France-Télécom pour la téléphonie classique rtc et
chez OVH pour la VoIP. Depuis un poste VoIP, j'établis une communication
avec un poste rtc situé à un mètre du précédent et j'envoie une
fréquence pure de 1750 Hz. Par l'entrée ligne de ma carte son,
j'enregistre simultanément pendant 3 minutes en stéréophonie le signal
émis et le signal reçu dans ce fichier OVH-FT-1750Hz-pur.ogg :
http://cjoint.com/?0BowOObHisP
J'édite le fichier avec Audacity, j'ajuste les gains des deux voies pour
obtenir des amplitudes sensiblement égales, puis je réunis par addition
les deux signaux et j'enregistre le résultat dans ce fichier
OVH-FT-1750Hz-battement.ogg :
http://cjoint.com/?CBowQmLG7Tn
Comme vous pouvez le voir sur cette image Battement.png :
http://cjoint.com/?0BowMeZ7wDl
un phénomène de battement met en évidence une faible différence entre la
fréquence émise et la fréquence reçue d'environ 8 ppm en relatif, sauf
erreur de ma part.

Comment expliquer ce décalage ?

Bonjour Géo.
L'appel sortant via la VoIP passe par une gateway chez OVH, donc un
CODEC qui n'est certainement pas un G711, mais plus probablement un G729.
Puis il y a un nouveau transcodage G729 -> G711 dans le central FT avant
conversion numérique - analogique et émission sur ta ligne FT.
Il n'est pas idiot de penser que le transcodage n'est pas fidèle en
fréquence. En effet, il y a une différence forte de fréquence
d'échantillonnage entre les deux CODEC (en plus de la différence de
quantification sur certaines plages de fréquence). Donc le résultat sur
le spectre en fréquence n'est pas garanti.
Au delà du cas du T38 dont tu parles (et ce n'est pas le sujet), c'est
pour ces raisons que certains CODEC très optimisés pour les voix
européennes s'avèrent nuls sur des voix vocalisées très différemment (en
Asie par exemple). Idem pour les erveurs vocaux.
C'est une contribution, pas forcément une vérité.
Didier.

Le 15/02/2013 11:17, *JKB* a écrit fort à propos :

Beaucoup de serveurs SIP refusent ce codec même s'il est forcé par
le terminal. Es-tu réellement sûr que le dialogue se fait avec ce
codec et non avec l'un des codecs de base ? Avec mon terminal Cisco,
je suis obligé de mettre des préférences et 9 fois sur 10, lorsque
j'appelle un numéro VoIP classique (Free et autres), le codec
bascule vers du 8 kbps. Si je force le G.711a seul, il m'est
impossible de téléphoner à madame Michu et sa box SFR/Orange ô
désespoir/Free et consorts.

Je n'ai pas les moyens de vérifier que c'est bien celui effectivement
utilisé mais tous les autres codecs sont désactivés. En outre, l'option
symmetriccodec est "enabled", ce qui est censé interdire l'emploi d'un autre
codec dans les deux sens de transmission, si je comprends bien. (?) Ceci
dit, je téléphone souvent à Mme Michu et à ses cousines clientes de divers
opérateurs, sans difficulté particulière. :-)

Si tu n'observes pas ce genre de chose avec le même codec, alors tu peux
envoyer et recevoir des fax ? C'est justement ce souci avec les fax que je
cherche à comprendre, et je souhaiterais une explication plus détaillée...

Le problème des fax est lié à l'ordre des paquets. Rien ne garantit
que la communication arrive dans l'ordre. Pour la voix, un taux
d'erreur binaire de 1E-2 est acceptable. Pour un fax, ça ne passe
pas. Le seul moyen de faire passer un fax sur de la VoIP est
d'avoir une QoS sévère (et un réseau VoIP dédié du côté de
l'opérateur... Je ne connais qu'un seul opérateur qui ait un tel
réseau dédié).

Quel opérateur ? Ça peut certainement intéresser des gens.

Pour ce qui est de l'ordre d'arrivée des paquets, je n'ai pas constaté une
seule erreur sur plus de deux minutes lors de l'expérience réalisée
aujourd'hui. J'ai envoyé sur la ligne du 2000 Hz modulé en amplitude par un
signal en marches d'escalier, la durée de chaque palier étant de 8 ms. À
l'arrivée, j'ai pu monter et descendre les quelques 15000 marches sur la
totalité de mon enregistrement sans trébucher une seule fois. Ouf ! Pour les
sportifs qui voudraient vérifier, je dépose un échantillon ici :

http://cjoint.com/?0Bpx4D1Ad6r

Les critiques éventuelles sont les bienvenues.

Il faut donc deux chsoes : QoS côté abonné (dans le modem et le
terminal VoIP qui doit tagguer correctement les paquets) et réseau
dédié côté opérateur. Sans cela, ça fonctionne aléatoirement en
fonction de la vitesse du vent ;-)

Comme tous les autres je suppose, mon modem priorise les flux de données de
son propre ATA incorporé, mais je ne pense pas qu'il marque les paquets aux
fins de leur assurer une priorité sur tout leur parcours. D'ailleurs, cette
priorité serait-elle honorée ?

Fu2 et suivi sur fr.reseaux.telecoms.techniques svp

Le 16/02/2013 00:21, geo cherchetout a écrit :

Le 15/02/2013 11:17, *JKB* a écrit fort à propos :

Beaucoup de serveurs SIP refusent ce codec même s'il est forcé par
le terminal. Es-tu réellement sûr que le dialogue se fait avec ce
codec et non avec l'un des codecs de base ? Avec mon terminal Cisco,
je suis obligé de mettre des préférences et 9 fois sur 10, lorsque
j'appelle un numéro VoIP classique (Free et autres), le codec
bascule vers du 8 kbps. Si je force le G.711a seul, il m'est
impossible de téléphoner à madame Michu et sa box SFR/Orange ô
désespoir/Free et consorts.

Je n'ai pas les moyens de vérifier que c'est bien celui effectivement
utilisé mais tous les autres codecs sont désactivés. En outre, l'option
symmetriccodec est "enabled", ce qui est censé interdire l'emploi d'un
autre codec dans les deux sens de transmission, si je comprends bien.
(?) Ceci dit, je téléphone souvent à Mme Michu et à ses cousines
clientes de divers opérateurs, sans difficulté particulière. :-)

Si tu n'observes pas ce genre de chose avec le même codec, alors tu peux
envoyer et recevoir des fax ? C'est justement ce souci avec les fax
que je
cherche à comprendre, et je souhaiterais une explication plus
détaillée...

Le problème des fax est lié à l'ordre des paquets. Rien ne garantit
que la communication arrive dans l'ordre. Pour la voix, un taux
d'erreur binaire de 1E-2 est acceptable. Pour un fax, ça ne passe
pas. Le seul moyen de faire passer un fax sur de la VoIP est
d'avoir une QoS sévère (et un réseau VoIP dédié du côté de
l'opérateur... Je ne connais qu'un seul opérateur qui ait un tel
réseau dédié).

Bonjour à tous.
Je ne suis pas sûr que le pb des fax soit lié à l'ordre des paquets.
D'autant que, contrairement aux fluxx temps réel comme la voix, on peut
les buffériser quasiment autant qu'on veut (le fax entier si on veut et
si on peut).
Par contre c'est extrêmement sensible aux codec (on ne code pas un
signal continu en fréquences, mais un ensemble de paires de fréquences,
un codec fait pour la voix humaine peut passer à côté).
Didier.

Le 16/02/2013 10:14, *Didier* a écrit fort à propos :

Bonjour à tous.
Je ne suis pas sûr que le pb des fax soit lié à l'ordre des paquets.
D'autant que, contrairement aux fluxx temps réel comme la voix, on peut
les buffériser quasiment autant qu'on veut (le fax entier si on veut et
si on peut).

Peut-être, mais dans la box ou l'ATA de tout un chacun il n'est question de
transmettre que la voix. On bufférise peut-être mais sûrement le moins
possible. La question de l'ordre des paquets à l'arrivée me semble donc
mériter d'être posée quand on essaie d'échanger des fax par cette voie.

Par contre c'est extrêmement sensible aux codec (on ne code pas un
signal continu en fréquences, mais un ensemble de paires de fréquences,
un codec fait pour la voix humaine peut passer à côté).
Didier.

Pas de souci de ce genre avec le G.711-a, mais j'aimerais savoir si mon
choix de codec est respecté tout le long de la chaîne entre mon modem-ATA et
le téléphone rtc de mon interlocuteur (moi-même en l'occurence). Quel est le
chemin entre le gateway d'OVH et mon central téléphonique ? C'est là que
pourrait se situer le danger, non ?

Le 16/02/2013 13:05, geo cherchetout a écrit :

Pas de souci de ce genre avec le G.711-a, mais j'aimerais savoir si mon
choix de codec est respecté tout le long de la chaîne entre mon
modem-ATA et le téléphone rtc de mon interlocuteur (moi-même en
l'occurence). Quel est le chemin entre le gateway d'OVH et mon central
téléphonique ? C'est là que pourrait se situer le danger, non ?

Pas de souci avec le G711, mais il est fortement probable qu'il soit
transcodé en cours de route. Donc c'est bien là le risque.
Un opérateur de réseaux se réserve toujours le droit de faire les choix
techniques sur son réseau.
Un petit complément sur l'ordre des paquets : le débit est faible en
mode fax (sauf si tu émules du groupe 4, mais ce serait incompatible
avec l'interface Z de ta box et de ta ligne FT); donc on peut bufferiser
sans problème. Je crois vraiment que le problème avec ce qui n'est pas
de la voix humaine, ce sont les codecs utilisés sur le parcours de la
session.
Didier.

Le 16/02/2013 14:08, *Didier* a écrit fort à propos :

Pas de souci avec le G711, mais il est fortement probable qu'il soit
transcodé en cours de route. Donc c'est bien là le risque.
Un opérateur de réseaux se réserve toujours le droit de faire les choix
techniques sur son réseau.
Un petit complément sur l'ordre des paquets : le débit est faible en
mode fax (sauf si tu émules du groupe 4, mais ce serait incompatible
avec l'interface Z de ta box et de ta ligne FT); donc on peut bufferiser
sans problème. Je crois vraiment que le problème avec ce qui n'est pas
de la voix humaine, ce sont les codecs utilisés sur le parcours de la
session.
Didier.

OK, merci pour cet avis et les précédents. Pour vérifier cette hypothèse, je
vais tenter de faxer à travers une liaison par softphone (Linphone ou
Ekiga). Ça ne va pas être facile mais, si j'y parviens, au moins serai-je
maître du codec de bout en bout.

Le 16/02/2013 15:36, geo cherchetout a écrit :

OK, merci pour cet avis et les précédents. Pour vérifier cette
hypothèse, je vais tenter de faxer à travers une liaison par softphone
(Linphone ou Ekiga). Ça ne va pas être facile mais, si j'y parviens, au
moins serai-je maître du codec de bout en bout.

Bonsoir Géo.
Explique-moi la manip : par softphone, tu veux dire un logiciel de fax ?
Mais si le test consiste à passer par la ligne VoIP, tu ne maîtriseras
toutjours pas le codec ches OVH ?
J'ai un peu eprdu le fil d'origine, mais as-tu fais l'essai en sens
inverse (ligne FT vers ligne OVH) ?
Didier.

Le 16/02/2013 18:35, *Didier* a écrit fort à propos :

Bonsoir Géo.
Explique-moi la manip : par softphone, tu veux dire un logiciel de fax ?

Non je veux dire un logiciel de téléphonie via internet. Établir la
communication vocale entre deux ordinateurs puis remplacer à chaque
extrémité casque et micro par un modem analogique. La difficulté principale
serait la réalisation de la transition deux fils/quatre fils.

Mais si le test consiste à passer par la ligne VoIP, tu ne maîtriseras
toutjours pas le codec ches OVH ?

On peut communiquer « gratuitement » entre ordinateurs sans recourir à un
opérateur de téléphonie. :-) Et on a alors le choix entre plusieurs codecs,
il suffit de se mettre d'accord sur celui qu'on préfère. (Sauf avec Skype,
je crois.)

J'ai un peu eprdu le fil d'origine, mais as-tu fais l'essai en sens
inverse (ligne FT vers ligne OVH) ?

L'essai de fax ? Franchement non parce que le tarif n'est pas le même. Mais
des mesures de temps de latence oui et vérifier l'ordre d'arrivée des
paquets c'est prévu. Le décalage en fréquence, je ne m'en soucie plus.
Serais tu volontaire pour quelques petites manips avec moi ? Mon adresse de
réponse est toujours valide.

L'itinéraire d'une communication téléphonique faisant appel à deux
opérateurs différents dépend-il de qui l'établit ?

Le 16/02/2013 20:22, geo cherchetout a écrit :

L'essai de fax ? Franchement non parce que le tarif n'est pas le même.
Mais des mesures de temps de latence oui et vérifier l'ordre d'arrivée
des paquets c'est prévu. Le décalage en fréquence, je ne m'en soucie
plus. Serais tu volontaire pour quelques petites manips avec moi ? Mon
adresse de réponse est toujours valide.

Je suis nul en électronique et tout ce qui va avec.
Côté professionnel, j'ai délaissé la technique pour le domaine de la
formation, donc je n'ai plus mon équipe d'experts pour monter des manip.

L'itinéraire d'une communication téléphonique faisant appel à deux
opérateurs différents dépend-il de qui l'établit ?

En VoIP, c'est assez compliqué.
A mon avis, l'itinéraire (au sens des équipements traversés) dépend de
la nature de la session (voix, data, fax etc ...), nature qui peut être
multimedia, des capacités de la première gateway rencontré en arrivant
chez le premier opérateur (les plus anciennes ont moins de capacités,
mais il faut bien les rentabiliser, alors on les garde), et bien sûr de
la famille de protocole utilisée (SIP ou H323). Le proxy (SIP) ou le
gatekeeper (H323) va devoir faire le choix des gateways par lesquelles
transitera la session; ce choix peut changer d'une session à l'autre
pour des raisons d'équilibrage de charge (entre autres). Mais cette info
est inacessible à nous utilisateurs finaux.
Donc je crains que tu n'aies du mal à tirer des conclusions.
Didier.