Reprise du message précédent :
ayé, j'ai viré le condo à 3 papattes j'attends impatiemment les nouvelles caractéristiques de ligne. Est ce que ces caractéristiques vont être mises à jour si ma freebox n'est pas reliée à un pc mais juste a la ligne FT ?

 
Exact.
Il existe d'autres codecs moins gourmants en bande passante mais je crois que fre utilise celui à 64 kb. Pour info le gsm c'est un codec à seuelement 16kb et ça marche aussi très bien ...
 
A savoir aussi que bon nombres des materiels VOIP savent gérer les blancs, afin de diminuer le trafic. C'est surement le cas de la freebox. ainsi on n'a pas 64kb en continu.

l'intérêt du 64kb (8bit à 8000hz), c'est que c'est standard, ça doit simplifier les échanges avec FT
et puis c'est pas compressé, donc c'est bien

Si c'est compressé! Dans tous les cas c'est compressé!
Pour les échanges avec FT, ça n'a rien à voir. Free doit acheminer le flux compressé vers des carriers qui font la passerelle (PSTN) avec le réseau "classique", qui au passage n'est pas forcément FT (free propose l'international aussi).

heu d'apres ce que Rani et Alec ont dit, c'est du PCM donc non compressé !
 
et d'ailleur quand on recoit un message repondeur par mail, le fichier son c'est bien du PCM non compressé

Mais en 64 kb c'est ça? Je m'y connais pas trop en PCM mais si c'est vraiment de la VOIP en PCM c'est bien dommage car c'est vraiment pas optimisé alors
C'est pas free qui décompresse en PCM lors de l'envoi du mail ?

oui = 8ko/s
 
apparement, le format utilisé pour le tel Freebox c'est bien :
PCM 8000Hz, 8bit, mono

c'est aussi le format utilisé pour numeris, et aussi sur les lignes analogiques FT standard (sauf que c'est FT qui numérise dans ce cas)
 
on m'a appris que tous les échanges se faisaient en 64kbit non compressé, si c'est pas le cas, ça va raler

Ok, je vois, bah pkoi pas. Ca marche aussi. Mais ça ne tire pas vraiment partie des nouvelles technologies VOIP prévues par le H.323.
M'enfin on s'en fout à vrai dire, tant qu'on peut appeller moins cher et correctement .. Je pense que c'est pour des raisons de coût de prod de la freebox et d'équipements réseaux. Surement plus cher que le surplus de bandepassante induit.

Je suis connecté depuis samedi dernier :
mais il ont l'air d'avoie des pbms de mise a jour
 
Question : la facturation a commencé ou bien ca sera seulement a l'activation complete ?
 

la facturation commence à la première connection

quelqu'un a une idée sur la durée de l'etape 4/5 svp ?
merci

je suis passé de l'etape 2 a la 5 en quasi 24h, mais ca peut varier d'apres ce que je sais

moi on m'as dis 1 semaines environ.

oki merci

Pour ceux qui ont suivi mes probleme de debit/synchro/deco, actuellement, j'ai des zero partout dans les carac de ma ligne sur le site de free.
Cela voudrait-il dire qu'ils sont en train de bosser dessus ?
Sa marche qd meme actuellement meme si j'ai un debit entre 1024 et 512kbps (en fb)

message bizarre de Rani sur pfad :
 

 
les freeboxés, ça vous prend combien sur l'up quand vous downloadez à 580ko/s ?
 
parce qu'à 250ko/s sur un sagem, ça bouffe même pas le quart de l'upload
 
Win2000 gère pas le SACK à ce que je sache

Un tracert sur ma ligne actuellement donne ca :
 
 
C:\Documents and Settings\User>tracert www.free.fr
 
Détermination de l'itinéraire vers www.free.fr [213.228.0.42]
avec un maximum de 30 sauts :
 
  1    <1 ms    <1 ms    <1 ms  . [192.168.2]
  2    40 ms    40 ms    41 ms  stdenis-3-82-66-235-fbx.proxad.net [82.66.235]
  3    40 ms    39 ms    40 ms  cbv-6k-1-a5.dslg.proxad.net [213.228.8]
  4    41 ms    41 ms    39 ms  vlq-6k-1-a6.routers.proxad.net [213.228.3]
  5    44 ms    41 ms    43 ms  www1.free.fr [213.228.0]
 
Itinéraire déterminé.

 
Pour avoir la freebox  
 
 
 
 
C'est que suite à un déménagement nous avons eu un nouveau numéro qui était celui d'une ancienne entreprise.
Tout les soirs le téléphone sonnait car on recevait des fax et ce en pleine nuit.

SackOpts  
Clé : Tcpip\Parameters  
Type de valeur : REG_DWORD : booléen  
Plage valide : 0, 1 (faux, vrai)  
Par défaut : 1 (vrai)  
Description : ce paramètre détermine si la prise en charge de la fonction accusé de réception sélectif (SACK, défini dans la RFC 2018) est activée ou non.
 
bien sur que oui il le gére et par defaut !

bah alors son excuse est bidon

En même temps il a dit qui font du SACK *correctement*, pas du SACK tout court

ça le fait suffisament correctement pour pas saturer l'upload

Oui, je sais bien, d'ailleurs je lui ai posé la question sur le newsgroup tout à l'heure

ah
je ne verrais que la réponse vu que je filtre pour avoir que les messages des corp

bah en même temps TcpOptimizer ne donne pas forcément de bon réglage correct pour que le sack s'éxécute correctement au dépît des performances. une fenêtres TcpWindowSize, un MTU et un MSS mal configuré peu trés bien faire foiré les options SACK
 
quelques info sur la gestion du SACK de Win2K (valable aussi pour NT4 mise à jour SP6a et XP !)
 
Accusé de réception TCP sélectif (RFC 2018)
Windows 2000 introduit la prise en charge d?une importante fonctionnalité qui améliore les performances, à savoir Accusé de réception sélectif (SACK). La fonction SACK est particulièrement importante pour les connexions caractérisées par des grandes dimensions de fenêtres TCP. Avant SACK, un récepteur pouvait seulement accuser réception du dernier numéro de séquence de données contiguës reçues, ou du bord gauche de la fenêtre de réception. Quand la fonction SACK est activée, le récepteur continue d?utiliser le numéro ACK pour accuser la réception du bord gauche de la fenêtre de réception, mais il peut également accuser réception individuellement d?autres blocs de données non contigus. La fonction SACK utilise les options d?en-tête TCP, comme indiqué ci-dessous. Ce texte a été directement extrait de la RFC 2018 :  
Option Sack-Permitted  
Cette option de deux octets est susceptible d?être envoyée dans un SYN par un protocole TCP à même de recevoir (et probablement de traiter) l?option SACK après l?ouverture de la connexion. Elle NE DOIT PAS être envoyée sur des segments autres que SYN.  
Option TCP Sack-Permitted :
Kind: 4
+---------+---------+
| Kind=4 | Length=2|
+---------+---------+  
Format de l?option SACK
L?option SACK doit être utilisée pour convoyer de grandes quantités d?accusés de réception entre un récepteur et un expéditeur sur une connexion TCP active.  
TCP SACK Option:
Kind: 5
Length: Variable
+--------+--------+
| Kind=5 | Length |
+--------+--------+--------+--------+
| Left Edge of 1st Block |
+--------+--------+--------+--------+
| Right Edge of 1st Block |
+--------+--------+--------+--------+
| |
/ . . . /
| |
+--------+--------+--------+--------+
| Left Edge of nth Block |
+--------+--------+--------+--------+
| Right Edge of nth Block |
+--------+--------+--------+--------+  
Quand l?option SACK est activée (par défaut), un ou plusieurs paquets peuvent être perdus et le récepteur est à même d?informer l?expéditeur sur les données exactes qui ont été reçues et donc sur les données manquantes. L?expéditeur peut ensuite retransmettre de manière sélective les données manquantes, sans besoin de retransmettre les blocs de données qui ont déjà été reçus avec succès. L?option SACK est gérée par le paramètre de registre SackOpts. La capture d?écran du Moniteur réseau ci-dessous montre un hôte qui accuse réception de toutes les données jusqu?à la séquence 54857341, ainsi que les données de la séquence 54858789-54861685.  
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x1A0D; Proto = TCP; Len: 64
TCP: .A...., len:0, seq:925104-925104, ack:54857341, win:32722,
src:1242 dst:139
TCP: Source Port = 0x04DA
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 925104 (0xE1DB0)
TCP: Acknowledgement Number = 54857341 (0x3450E7D)
TCP: Data Offset = 44 (0x2C)
TCP: Reserved = 0 (0x0000)
+ TCP: Flags = 0x10 : .A....
TCP: Window = 32722 (0x7FD2)
TCP: Checksum = 0x4A72
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
+ TCP: Timestamps Option
TCP: Option Nop = 1 (0x1)
TCP: Option Nop = 1 (0x1)
TCP: SACK Option
TCP: Option Type = 0x05
TCP: Option Length = 10 (0xA)
TCP: Left Edge of Block = 54858789 (0x3451425)
TCP: Right Edge of Block = 54861685 (0x3451F75)

 
arf ok je comprends mieux !

Qui peut me faire un tracert sur free.fr pour comparé avec le mien page 243

 
 
       
 
c'est bon ! I'm a Real Freenaute

Je suis passé en faspath hier et g ca :
Fec 0 (far) 0 (near)  
Hec 1 (far) 0 (near)  
Crc 4 (far) 0 (near)  
alors qu'en interleave j'avais que des 0 partout (
 Interleave  
  Fec 0 (far) 0 (near)  
  Hec 0 (far) 0 (near)  
  Crc 0 (far) 0 (near)  
)
 
Je me demande ce que ces valeurs peuvent vouloir dire exactement et si c à cause du changement en faspath que ca a changé

c'est la classe! depuis hier j'avais des deco/reco tout les min: impossible de surfer koi
et la j'arrive, le net marche et je vois 4576Kbps  (en sagem degroupé)
ca veut dire que ma freebox arrive? ^^

non
 
que tu es sur un DSLAM débridé pour les SAGEM hier soir.

tracert www.free.fr
 
Détermination de l'itinéraire vers www.free.fr [213.228.0.42]
avec un maximum de 30 sauts :
 
  1     7 ms     7 ms     7 ms  8X.XXX.XX.XXX
  2     8 ms     7 ms     7 ms  toulouse-6k-1-a5.dslg.proxad.net [213.228.9.254]
 
  3    22 ms    22 ms    22 ms  cbv-6k-1-a0-s.routers.proxad.net [213.228.2.253]
 
  4    22 ms    23 ms    23 ms  vlq-6k-1-a6.routers.proxad.net [213.228.3.1]
  5    24 ms    23 ms    23 ms  www1.free.fr [213.228.0.42]
 
Itinéraire déterminé.

 
tu as branché ta Freebox et ca marche ?

merci biens
 
actuellement j'ai ca :
 

vdh53, tu es en interleave bas ou fast path ?

je suis en faspath

non, windows marque toujours < (inférieur) à 1ms !

Ouai j'ai regarder trop vite, et j'ai effecer trop lentement !