Admins

QGull a testé en appelant le numéro de conf call (extension 84) et le problème s'est produit au bout de 30 mn.
Les messages affichés par rasterisk :
Apr 12 14:38:19] WARNING⁶¹⁷⁴: chan_sip.c:20457 handle_response_invite: just did sched_add waitid(325613) for sip_reinvite_retry for dialog 2470ad4f2f623297511b16725827770b@217.146.224.159:5060 in handle_response_invite
[Apr 12 14:38:27] WARNING⁶¹⁷⁴: chan_sip.c:3656 retrans_pkt: Retransmission timeout reached on transmission 2470ad4f2f623297511b16725827770b@217.146.224.159:5060 for seqno 105 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[Apr 12 14:38:27] WARNING⁶¹⁷⁴: chan_sip.c:3685 retrans_pkt: Hanging up call 2470ad4f2f623297511b16725827770b@217.146.224.159:5060 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions). == Spawn extension (default, 84, 1) exited non-zero on 'SIP/axialys-00000043'

Coolgeek a testé en appelant le numéro d'Etienne (extension 82) et le problème s'est produit au bout de 22 mn.

Les messages affichés par rasterisk :
[Apr 12 15:11:30] WARNING[6174]: chan_sip.c:20457 handle_response_invite: just did sched_add waitid(326573) for sip_reinvite_retry for dialog 7c3c03786a54cf967311afb8588e7ab5@217.146.224.196:5060 in handle_response_invite
[Apr 12 15:12:22] WARNING[6174]: chan_sip.c:3656 retrans_pkt: Retransmission timeout reached on transmission 7c3c03786a54cf967311afb8588e7ab5@217.146.224.196:5060 for seqno 104 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 51520ms with no response
[Apr 12 15:12:22] WARNING[6174]: chan_sip.c:3685 retrans_pkt: Hanging up call 7c3c03786a54cf967311afb8588e7ab5@217.146.224.196:5060 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
  == Spawn extension (default, 82, 3) exited non-zero on 'SIP/axialys-00000047'

• asterisk répond "erreur, j'ai déjà une requête en cours"
• le distant répond "j'essaie" puis "cette session n'existe plus" (suite au message d'erreur d'asterisk)

ça se termine en bataille (je passe les détails) pendant 2 minutes avec le distant qui met fin à tout ça avec un BYE.

Je ne suis pas expert de la rfc4028 "Session Timers in the Session Initiation Protocol (SIP)", donc je ne peux pas dire lequel des 2 côtés fait mal les choses.
Le principal dans un premier temps étant de rétablir la situation, je dirais qu'il faut voir du côté des paramètres d'asterisk pour désactiver le "session expire" côté asterisk, ou augmenter grandement le timer, ou passer le timer à une valeur qui ne peut pas être divisée par 1200..
Je ne connais pas bien asterisk, je me renseigne.

Je vois plusieurs paramètres intéressant pour ce cas :
;session-timers=originate
originate : Request and run session-timers always
accept : Run session-timers only when requested by other UA
refuse : Do not run session timers in any case

passer à "accept" pourrait régler le soucis, mais je ne recommande pas forcement.

;session-expires=600
on peut voir si le problème n'est plus présent avec un session-expires à 595 :)

Salut,

Pourriez-vous me donner la version d'Asterisk et me donner sans les login et password la configuration vers Axialys du trunk sip.

En passant, les logs donnés sont simplement des warnings, donc le best serait d'avoir la trace SIP quand ça raccroche. Autre point Asterisk à un mécanisme pour détecter s'il n'y a plus de RTP et raccroche la communication, donc peut être que vous avez aussi ce problème. Mais si c'est toujours 20 ou 30 minutes, y a sûrement autre chose. Concernant les timers SIP, ce n'est pas obligatoire, je dirai même que vous pourriez les enlever pour le moment pour enlever la probabilité que le problème vient de là.
Avez vous demandé à Axialys s'il y avait une limite de temps aussi ? Le problème est il juste externe vers interne et inverse ou alors l'interne et concerné ?

Asterisk :

Version: 1:1.8.13.1~dfsg1-3+deb7u3
Provides: asterisk-1.8

[axialys]
context=from-iax
type=peer
fromdomain=sip-ng.axialys.net
host=sip-ng.axialys.net
qualify=yes
disallow=all
allow=alaw
allow=ulaw
nat=yes
insecure=port,invite
localnet=192.168.3.0/255.255.255.0
dtmfmode=inband

Le problème est externe vers interne.

J'ai fait un test d'appel de l'interne vers mon téléphone mobile et ça tient visiblement (toujours pas déconnecté au bout de 40 minutes).

Le problème est identique (mais plus clair car 1 seul échange de re-INVITE) avec le session-expire=595.
Je remarque que le problème que j'observe est le même que celui décrit ici : https://issues.asterisk.org/jira/browse/ASTERISK-11458
canreinvite=no ne fonctionne pas non plus.

La trame SIP qui a été mise est une coupure venant de l'appelant ou Axialys avec une cause 16 (normal), je ne vois pas grand chose d'anormal dedans. Concernant l'autre ticket, je ne suis pas sûr de voir le lien. Le canreinvite sert à passer le media directement entre l'appelant et l'appelé dans votre cas entre le téléphone SIP et le trunk SIP dans passer par l'Asterisk. Si votre Asterisk est dans vos locaux pas besoin de le mettre. Concernant la configuration, le localnet ne fonctionne pas dans un peer, c'est une option du général en passant. Sinon le codec ulaw est normalement nord américain donc tu peux mettre juste alaw.
Donc si je comprends bien, j'appelle depuis l’extérieur vers chez vous et au bout de 20 minutes, l'appel coupe tout le temps. Concernant le SIP timer, perso je supprimerai pour le moment pour vérifier cette hypothèse.
Comme j'ai dis à Fred, je peux passer au bureau pour aider à trouver la solution la semaine prochaine. Je serai à Paris lundi, mardi et mercredi matin, on pourra aussi demander à Axialys des logs de leur côté si besoin.

Sylvain, tu peux voir sur la trace que l'asterisk répond au re-INVITE d'Axialys (déclanché par le Session-Expire) par un "491 Request Pending", ce qui provoque la fermeture de la session chez Axialys qui répond ensuite aux re-INVITE d'asterisk par un "481 Call/Transaction Does Not Exist".
Après lecture (rapide) de la section "Glare Case Handling" de la rfc6337 "Session Initiation Protocol (SIP) Usage of the Offer/Answer Model" (https://tools.ietf.org/html/rfc6337#section-4.2), la réponse d'asterisk est conforme. Par contre, il ne me semble pas que cela devrait mettre fin à la session côté Axialys.
Je pense qu'on peut ouvrir un ticket chez eux, leurs experts auront probablement un avis sur le sujet.

En solution de contournement, si l'asterisk ne faisait pas de re-INVITE, alors il n'y aurait pas de problème de "glare condition". Mais je ne sais pas comment régler cela.
"Concernant le SIP timer, perso je supprimerai", comment on fait ça ?

Tu peux faire cela :

session-timers = refuse

Pour le reinvite essaie plutôt :

directrtpsetup = no
directmedia = no

Aussi c'est surprenant de voir du dtmf inband, pourquoi ne pas mettre le traditionnel rfc2833 ? C'est Axialys qui impose cela ?

À noter la configuration particulière au niveau réseau (suite à un autre bug dont je vais saisir le ticket) : les connexions internet depuis le local sortent par notre connexion OVH sauf la téléphonie qui sort par le réseau d'Easter-Eggs.
Pour comprendre le réseau : nous avons un modem-routeur OVH, un serveur nommé opium qui nous sert de passerelle entre le réseau local et la box OVH. Sur opium, il y a une machine virtuelle nommée scopolamine sur laquelle il y a le serveur asterisk. Opium a deux cartes réseaux et, grâce à un script /usr/local/sbin/changenet on peut sortir via notre box ADSL ou via le réseau/la connexion d'Easter-Eggs.
Sur opium, il y a actuellement une route ajoutée pour que la téléphonie sorte par le réseau Easter-Eggs :
/sbin/ip ro add 217.146.224.0/24 via 10.2.0.1

Concernant le dtmfmode=inband iirc c'était pour régler un problème lié, mais en fait la valeur n'est pas bonne car selon https://agir.april.org/issues/1683 cela doit être dtmfmode=info.
Je viens de faire des tests et seule la valeur dtmfmode=info permet de ne pas avoir "that pin number is invalid" quand on appelle la conf room de la FSF.

J'ai ajouté dans le bloc [general] du fichier /etc/asterisk/sip.conf :
session-timers=refuse
directrtpsetup = no
directmedia = no
Des tests semblent montrer que cela résoudrait le problème. Un appel extérieur tient plus de 1h.

Pour régler le bug https://agir.april.org/issues/1700 on a du remettre les variables externip (avec l'adresse IP de sortie) et localnet dans sip.conf le problème de deconnexion ne se produit plus, qu'on soit connectés via la connexion internet de l'April ou celle d'Easter-Eggs.

En cas de changement de reséau, il faut donc changer la valeur de externip et donc modifier le script de changement de réseau en conséquence.