[spyman28]

slt
en 1er codec si possible met 711u en 2eme 729a et en 3eme le 722

[hippo44000]

Bon alors, verdict depuis vendredi... plus de perte d'appels. C'était bien le RV042 qui posait problème.
Maintenant, je n'ai plus qu'un souci de qualité des appels avec ma livebox pro v3 en fibre. Plutôt de manière aléatoire d'ailleurs. Une SDSL OVH aurait peut-être été un choix plus judicieux, mais pour 5 postes, je pensais qu'un accès fibre en 200 mega devait le faire.

[spyman28]

slt
Desole de voir ton post un peu tard mais "apparentement le rv pose pas mal de soucis téléphonie" il route mal le sip et nat pas au bon moment
perso j utilise du tplink TL-R470T+ et aucun pb de nat sur 2 connections ovh en loadbalancer ni sur 1ovh et 1 orange-play en loadbalancer aussi

[hippo44000]

Bon verdict... derrière la livebox en fibre ça fonctionne bien depuis 15h00
finalement j'ai viré le RV042 et ça a l'air de rouler maintenant. Enfin...pour l'instant du moins. On verra au bout d'une semaine ce que ça donne.

[hippo44000]

Avec quel codec ?

ulaw alaw dans freepbx donc du 711a si j'ai bien tout suivi.

[hippo44000]

La je suis repassé avec la freebox en mode modem avec le RV042 et ça donne finalement la même chose qu'avec la freebox en mode routeur sans le RV042. Mais j'ai eu un appel perdu. Je commence à perdre mon latin avec ce truc.
Je vais essayer de passer en direct derrière la livebox pour voir ce que ça donne.

[Gaston_Phone]

tout simplement parce que la qualité audio est vraiment pas terrible. J'ai des coupures dans la conversation.
J'avais pris justement la fibre pensant que la qualité serait au rendez-vous tant en terme de débit que de latence mais bizarrement, c'est vraiment pas top.

Avec quel codec ?

[hippo44000]

Et verdict au bout d'une journée d'utilisation, en adsl free... ben pas top non plus. Plus d'appels perdus, mais qualité moyenne lors des conversation (des blancs pendant qu'on parle).

[hippo44000]

tout simplement parce que la qualité audio est vraiment pas terrible. J'ai des coupures dans la conversation.
J'avais pris justement la fibre pensant que la qualité serait au rendez-vous tant en terme de débit que de latence mais bizarrement, c'est vraiment pas top.

[Gaston_Phone]

sauf qu'avec la fibre orange et sa fameuse livebox, c'est franchement pas terrible pour le sip.

Et pourquoi ?

[hippo44000]

sauf qu'avec la fibre orange et sa fameuse livebox, c'est franchement pas terrible pour le sip. Si seulement on pouvait virer cette livebox et utiliser le modem fibre en direct ça serait top. Enfin, ceci est un autre débat

[Gaston_Phone]

Oui mais, un RV042 branché sur un seul wan... disons que ça perd quand même un peu de son intérêt non ?

Oui et non, il peut aussi servir pour protéger efficacement le réseau local.

[hippo44000]

Oui mais, un RV042 branché sur un seul wan... disons que ça perd quand même un peu de son intérêt non ?

[Gaston_Phone]

Cela devrait fonctionner quand avec le RV042 branchée sur un seul WAN.

[hippo44000]

Bon a priori ça a l'air de fonctionner correctement en direct sur la freebox. Pas un seul appel perdu depuis ce matin et la qualité du son est bonne.

Je pense que ça doit fonctionner quand même avec le RV042 et la freebox en mode modem. En effet, je me suis rendu compte que je passais tous les appels sur le WAN2 mais l’adresse ip que j'avais mise dans la config asterisk était celle du WAN1.
Je réessaierai avec le RV042 en changeant tout ça, mais plus tard. Là, les utilisateurs sont contents, ce n'est pas vraiment le moment de le dire que ça ne fonctionne plus ;-)

[hippo44000]

Ok je vais tester ça.

[laurentm]

j'ai eu beaucoup d'ennuis, parfois sans avoir rien changé pendant des mois, et en supprimant le "dual wan" et en mettant un routeur séparé pour la connexion internet qui me sert à la voip (SDSL perso à 25 euros ht/mois) je n'ai plus eu aucun ennui.
Il semble que parfois le NAT + les deux adresses ip WAN différentes perturbent la registration du compte SIP chez OVH et le FreePBX.
Maintenant j'ai le DHCP, et tous les PC sur la connexion adsl en 192.168.10.1
et le FreePBX a comme passerelle 192.168.10.2 sur la SDSL.
Les postes voip reçoivent la passerelle 192.168.10.1 par le DHCP, mais ce n'est pas gênant car ils n'ont pas besoin de passerelle pour joindre le FreePBX qui est dans le LAN.

[hippo44000]

non, mais je ne dis pas que le problème vient de chez eux. Je sais ou tout du moins, je me doute très fortement que ça vient d'une config de mon ipbx. J'ai vu passer des messages sur des forums en anglais à ce propos, mais comme le sujet était évoqué ici...

[Gaston_Phone]

Si tu ne court-circuites pas le Serveur FreePBX un moment, tu auras du mal à faire admettre au support OVH que le problème est chez eux.

[hippo44000]

As-tu essayé en court-circuitant Serveur FreePBX 2.11.0.11 ?

Ben disons que mon serveur freepbx c'est lui qui gère tous les postes en interne, je n'ai donc pas essayé de le supprimer ;-)
Le trunk OVH c'est ça : http://www.ovhtelecom.fr/telephonie/sip_trunk/index.xml
un groupement de ligne style numeris si tu veux.

[Gaston_Phone]

Trunk OVH
cisco RV042 pour le dual wan
freebox en mode modem (et qualité sonore est nettement meilleure maintenant que je l'ai passée comme ça)
Serveur FreePBX 2.11.0.11

As-tu essayé en court-circuitant Serveur FreePBX 2.11.0.11 ?

[Gaston_Phone]

Trunk OVH <--> Easy PABX ?

[hippo44000]

Trunk OVH
cisco RV042 pour le dual wan
freebox en mode modem (et qualité sonore est nettement meilleure maintenant que je l'ai passée comme ça)
Serveur FreePBX 2.11.0.11

après pour la config du trunk ça donne ça :

host=siptrunk.ovh.net
username=0033XXXXXXXXX  (mon num)
secret=xxxxxx
type=peer
qualify=yes
insecure=port,invite
fromuser=0033XXXXXXXXX (re- mon num)
fromdomain=siptrunk.ovh.net
context=from-trunk
canreinvite=no
amaflags=default

[Gaston_Phone]

Mais toujours les mêmes pertes d'appels.

Détails de ta configuration SIP ?

[hippo44000]

Perso je suis en ADSL dégroupé chez free ainsi qu'en fibre chez orange.
Je passais par la fibre pour mes appels, mais j'avais une mauvaise qualité (et aussi les mêmes pertes d'appels).
Je passe maintenant tous mes appels sur la ligne free et utilise la fibre pour le reste.
Mais toujours les mêmes pertes d'appels.

[1fopresta.com]

Bonjour,
juste une question, quel est votre type de connexion à Internet ?

[laurentm]

Il y a certainement des bugs dans FreePbx, mais avec la 2.9 les conférences ne fonctionnaient pas, problème réglé avec la 2.10

[kdaffef]

Je rencontre les mêmes ennuis sporadiquement... j'utilise aussi FreePbx. Parfois il faut désactiver et réactiver le trunk car plus aucun appel n'arrive, mais les appels sortants vont bien. Le problème est que l'on ne s'aperçoit pas forcément tout de suite de l'incident, je suggère donc aux utilisateurs de programmer un renvoi d'appel de la ligne principale du compte SIP (pas des DDI, car ce n'est pas faisable) vers un téléphone portable afin de se rendre compte quand un appel arrive dessus qu'on est dans ce cas de figure.

bjr, j'ai récupéré un backup d'avril où j'utilisais Piaf 2.0641 avec Freepbx 2.9, et là sans rien changer tout arrive parfaitement, aucun appel perdu ou routé vers le n° extérieur programmé sous "renvoi d'appel si indisponible..." dans le manager d'ovh.

Dans les deux cas de figure :
- Version mauvaise (appels perdus) : récente avec asterisk 1.8.21.0 + freepbx 2.10
- Version bonne (pas d'appels perdus) : asterisk 1.8.21.0 + freepbx 2.9

Le souci ne serait pas qq choses dans freepbx 2.10 ??

car dans les deux on utilise exactement la meme config des sip, asterisk, iptables.

A creuser plus loin, pour l'instant pour ceux qui sont avec freepbx 2.10, essayez de re-passer en 2.9 et attends votre commentaire de l'hypothèse ci-dessus !.

Bonne journée,

[laurentm]

Je rencontre les mêmes ennuis sporadiquement... j'utilise aussi FreePbx. Parfois il faut désactiver et réactiver le trunk car plus aucun appel n'arrive, mais les appels sortants vont bien. Le problème est que l'on ne s'aperçoit pas forcément tout de suite de l'incident, je suggère donc aux utilisateurs de programmer un renvoi d'appel de la ligne principale du compte SIP (pas des DDI, car ce n'est pas faisable) vers un téléphone portable afin de se rendre compte quand un appel arrive dessus qu'on est dans ce cas de figure.

[kdaffef]

Dans la console asterisk (asterisk -r) peux-tu essayer de faire un "sip show peers" et vérifier si toutes les ip que tu verras te sont bien connues.

Le 10.7.1.49, ce n'est pas l'ip de ton asterisk ?
N'as tu pas un téléphone ou softphone qui serait paramétré avec tes identifiants OVH ?

Aussi, essaye peut être de changer la destination de l'appel entrant pour l'envoyer vers une conférence par exemple ou un message automatique :
- si ça fonctionne : asterisk n'est plus forcément en cause, et cela pourrait être ton téléphone qui reçoit les appels qui est peut être en mode "Do Not Disturd" / 'Ne pas déranger'
- si ça ne fonctionne pas : asterisk est le problème et là ... faudra encore chercher.

- 10.7.1.49, ce n'est pas l'ip de ton asterisk : non du tout,
- le sip show peers donne tous les peers "OK" (reachable)

Alors, allons plus loin ....

[roms2000]

Dans la console asterisk (asterisk -r) peux-tu essayer de faire un "sip show peers" et vérifier si toutes les ip que tu verras te sont bien connues.

Le 10.7.1.49, ce n'est pas l'ip de ton asterisk ?
N'as tu pas un téléphone ou softphone qui serait paramétré avec tes identifiants OVH ?

Aussi, essaye peut être de changer la destination de l'appel entrant pour l'envoyer vers une conférence par exemple ou un message automatique :
- si ça fonctionne : asterisk n'est plus forcément en cause, et cela pourrait être ton téléphone qui reçoit les appels qui est peut être en mode "Do Not Disturd" / 'Ne pas déranger'
- si ça ne fonctionne pas : asterisk est le problème et là ... faudra encore chercher.

[kdaffef]

Peut-être une histoire de codec ?

Si l'appel arrive et est en g729 et que ton asterisk n'a pas ou n'accepte pas le g729, alors ça sonne puis ferme la connexion.

Essaye en ajoutant le g729 à asterisk, que tu trouveras sur http://asterisk.hosting.lv/

salut roms2000,

sincèrement je pense pas à un problème audio, voici l'état de mes investigations :
- l'appel est coupé quand il arrive dans asterisk pour la raison suivante :

---- extrait du log où l'appel est perdu :
CANCEL sip:0033xxxxxxxxxxx@mon-ext-ip:5060;transport=udp SIP/2.0
Call-ID: 10989-ZM-00e6ef69-568267ae1@sip.ovh.fr
CSeq: 15154821 CANCEL
From: "0664366197" ;tag=10989-WZ-00e6ef6a-13b334676
Max-Forwards: 29
To: 10.7.1.49;user=phone>
Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-RYMC-03db62f7-2865975a
Reason: q.850;cause=27
User-Agent: Cirpack/v4.42a (gw_sip)
Content-Length: 0

et Asterisk a repondu avec :

SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 91.121.129.20:5060;branch=z9hG4bK-RYMC-03db62f7-2865975a;received=91.121.129.20;rport=5060
From: "0664366197" ;tag=10989-WZ-00e6ef6a-13b334676
To: ;tag=as3f6461 d4
Call-ID: 10989-ZM-00e6ef69-568267ae1@sip.ovh.fr
CSeq: 15154821 INVITE
Server: FPBX-2.10.1(1.8.22.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

----------------------------------------------------------------------------------------

D'après le support la cause 27 est "ligne déconnectée" !!.

Question de payasan : si la ligne est déconnectée, pourquoi ovh lui dirige l'appel ??. Cela veut dire, quand l'appel a été dirigé depuis le serveur ovh, la ligne était bien connectée, mais pas à l'arrivée à notre asterisk !!.

Bref, j'ai tenté de restaurer une copie du disque depuis 4 mois (incluant freepbx 2.9.), et par coût de magie : tout marche et aucun appel perdu !!.


Conclusion : le problème est bien situé dans asterisk (lui meme ou freepbx, ...) et écarte un souci de : la connexion adsl et la téléphonie ovh apparemment !! et cette adresse dans le log : 10.7.1.49 reste l'énigme ?

Autre piste ??

[roms2000]

Peut-être une histoire de codec ?

Si l'appel arrive et est en g729 et que ton asterisk n'a pas ou n'accepte pas le g729, alors ça sonne puis ferme la connexion.

Essaye en ajoutant le g729 à asterisk, que tu trouveras sur http://asterisk.hosting.lv/

[kdaffef]

From: "Unknown" ;tag=as61933100

Je dis peut être bétise, as tu remarqué si ce sont des appels en numéro masqué qui plantent ?

Salut, pas forcément, car j'ai eu aussi des appels normaux avec des numéros qui s'affichent et ça planté aussi !.

Par contre, s'il y a des experts da,s le forum : il forecément quelques explications autour de la ligne qui précede le plantage :

"SIP/2.0 501 Not Implemented",

Il doit y manquer un petit truc au niveau déclaratif du trunk, non ??

[tanguyd]

From: "Unknown" ;tag=as61933100

Je dis peut être bétise, as tu remarqué si ce sont des appels en numéro masqué qui plantent ?

[kdaffef]

Bonjour,

Nous travaillons sur un serveur Asterisk (distribution pbxinaflash), dans un petit secrétariat tél. Depuis quelques temps, constatons des appels entrants perdus (car nous voyons le popup entrant sur l écran du poste opérateur), puis PLUS RIEN !!!

En fait l'appel a été acheminé par ovh jusqu'a Asterisk, puis il se trouve renvoyer vers un N°extérieur (renvoi d'appels dpuis le manager si ligne sip indisponible).

Nous constatons quelques 10 appels / perdus par jour de cette façon sur 150 gérés quotidiennement env.

Avez-vous eu le meme souci et si quelqu'un peut aider svp
D'avance merci

Ci-après, je joins des infos sur Iptables, trunck et asterisk log-files
==================================================

------------------------ Trunk ovh example config --------------------------------
username=0033XXXXXXXXX
type=peer
secret=Pass
restrictcid=no
qualify=yes
permit=91.121.129.20/255.255.255.255
nat=yes
insecure=port,invite
host=sip.ovh.fr
fromuser=0033XXXXXXXXX
fromdomain=sip.ovh.fr
dtmfmode=rfc2833
disallow=all
context=from-trunk
canreinvite=no
call-limit=2
amaflags=default
allow=ulaw

Registar : 0033XXXXXXXXX:Pass@sip.ovh.fr/0033XXXXXXXXX



------------------- IP Tables rules ----------------------------------------------

Accept If input interface is lo
Accept If protocol is TCP and TCP flags ACK (of ACK) are set
Accept If state of connection is ESTABLISHED
Accept If state of connection is RELATED
Accept If protocol is UDP and destination port is 1024:65535 and source port is 53
Accept If protocol is ICMP and ICMP type is 0
Accept If protocol is ICMP and ICMP type is 3
Accept If protocol is ICMP and ICMP type is 4
Accept If protocol is ICMP and ICMP type is 11
Accept If protocol is ICMP and ICMP type is 12
Accept If protocol is TCP and destination port is 22
Accept If protocol is TCP and destination port is 113
Accept If protocol is TCP and destination port is 80
Accept If protocol is TCP and destination port is 443
Accept If protocol is TCP and destination port is 21
Accept If protocol is TCP and destination port is 9001
Accept If protocol is TCP and destination port is 9080
Accept If protocol is UDP and destination port is 4569
Accept If protocol is UDP and destination port is 5000:5082
Accept If protocol is UDP and destination port is 10000:20000
Accept If protocol is TCP and destination port is 4445
Accept If protocol is TCP and destination port is 5038
Accept If protocol is UDP and destination port is 123
Accept If protocol is UDP and destination port is 69
Accept If protocol is TCP and destination port is 9022
Accept If protocol is UDP and destination port is 5353
Accept If source is 192.168.0.0/16
Accept If source is 172.16.0.0/12
Accept If source is 10.0.0.0/8
Accept If source is 127.0.0.0/8
Accept If protocol is UDP and source is 91.121.129.20 and destination port is 5000:5082
Accept If protocol is UDP and source is 91.121.129.20 and destination port is 10000:20000
Accept If protocol is TCP and source port is 23053
Accept If protocol is UDP and destination port is 5038
Accept If protocol is TCP and source is 192.168.0.0/16 and destination port is 8088


--------------------------------- Set SIP Debug on ----------- (exemple d appel perdu --------------------------------



[2013-07-03 12:30:19] VERBOSE[1778] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP ext-static_ip:5060;branch=z9hG4bK1bb88b70;rport
Max-Forwards: 70
From: "Unknown" ;tag=as74c7a235
To:
Contact:
Call-ID: 3ac0758f406007b13be1bff22efa29cb@ext-static_ip:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.10.1(1.8.22.0)
Date: Wed, 03 Jul 2013 10:30:19 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---
[2013-07-03 12:30:19] VERBOSE[1778] chan_sip.c:
<--- SIP read from UDP:91.121.129.20:5060 --->
SIP/2.0 501 Not Implemented
Call-ID: 690842081a107c267a413ba50faeb042@ext-static_ip:5060
CSeq: 102 OPTIONS
From: "Unknown" ;tag=as61933100
To: ;tag=00-30127-072dc5ed-720ee6f25
Via: SIP/2.0/UDP ext-static_ip:5060;received=ext-static_ip;rport=39428;branch=z9hG4bK48e7a834
Content-Length: 0

<------------->
[2013-07-03 12:30:19] VERBOSE[1778] chan_sip.c: --- (7 headers 0 lines) ---
[2013-07-03 12:30:19] VERBOSE[1778] chan_sip.c: Really destroying SIP dialog '690842081a107c267a413ba50faeb042@ext-static_ip:5060' Method: OPTIONS
[2013-07-03 12:30:19] VERBOSE[1778] chan_sip.c:
<--- SIP read from UDP:91.121.129.20:5060 --->
SIP/2.0 501 Not Implemented
Call-ID: 3ac0758f406007b13be1bff22efa29cb@ext-static_ip:5060
CSeq: 102 OPTIONS
From: "Unknown" ;tag=as74c7a235
To: ;tag=00-23427-072dc5ff-1e9d0c845
Via: SIP/2.0/UDP ext-static_ip:5060;received=ext-static_ip;rport=39428;branch=z9hG4bK1bb88b70
Content-Length: 0

<------------->
[2013-07-03 12:30:19] VERBOSE[1778] chan_sip.c: --- (7 headers 0 lines) ---
[2013-07-03 12:30:19] VERBOSE[1778] chan_sip.c: Really destroying SIP dialog '3ac0758f406007b13be1bff22efa29cb@ext-static_ip:5060' Method: OPTIONS
[2013-07-03 12:30:20] VERBOSE[1778] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP ext-static_ip:5060;branch=z9hG4bK63d71483;rport
Max-Forwards: 70
From: "Unknown" ;tag=as185de19b
To:
Contact:
Call-ID: 606166520e0522cf6d0d23e6601da1b9@ext-static_ip:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.10.1(1.8.22.0)
Date: Wed, 03 Jul 2013 10:30:20 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---
[2013-07-03 12:30:20] VERBOSE[1778] chan_sip.c:
<--- SIP read from UDP:91.121.129.20:5060 --->
SIP/2.0 501 Not Implemented
Call-ID: 606166520e0522cf6d0d23e6601da1b9@ext-static_ip:5060
CSeq: 102 OPTIONS
From: "Unknown" ;tag=as185de19b
To: ;tag=00-22855-072dc9dd-133d8d466
Via: SIP/2.0/UDP ext-static_ip:5060;received=ext-static_ip;rport=39428;branch=z9hG4bK63d71483
Content-Length: 0

<------------->
[2013-07-03 12:30:20] VERBOSE[1778] chan_sip.c: --- (7 headers 0 lines) ---
[2013-07-03 12:30:20] VERBOSE[1778] chan_sip.c: Really destroying SIP dialog '606166520e0522cf6d0d23e6601da1b9@ext-static_ip:5060' Method: OPTIONS
[2013-07-03 12:30:20] VERBOSE[1778] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP ext-static_ip:5060;branch=z9hG4bK71b57ca2;rport
Max-Forwards: 70
From: "Unknown" ;tag=as0e8554b5
To:
Contact:
Call-ID: 790185e136b023e45f2a352a545144e2@ext-static_ip:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.10.1(1.8.22.0)
Date: Wed, 03 Jul 2013 10:30:20 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---
[2013-07-03 12:30:20] VERBOSE[1778] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP ext-static_ip:5060;branch=z9hG4bK26acbd46;rport
Max-Forwards: 70
From: "Unknown" ;tag=as39f7be49
To:
Contact:
Call-ID: 07992e9404b247917079bdaa14bae006@ext-static_ip:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.10.1(1.8.22.0)
Date: Wed, 03 Jul 2013 10:30:20 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---
[2013-07-03 12:30:20] VERBOSE[1778] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP ext-static_ip:5060;branch=z9hG4bK7664ef06;rport
Max-Forwards: 70
From: "Unknown" ;tag=as5e3e9968
To:
Contact:
Call-ID: 060eb8f00f408e6718d39ec5383f7b5d@ext-static_ip:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-2.10.1(1.8.22.0)
Date: Wed, 03 Jul 2013 10:30:20 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0