XiVO Community

Et un jour plus tard, malgré avoir vidé le cache et testé avec plusieurs navigateurs avant de poster :

Logiciel : Asterisk
Version : 8:20.2.0-1~xivo1+deb11+20230315.160534.273eb27

La version affichée est bien à jour. (résultat de requête stocké ?)

Un grand merci à nouveau pour votre travail.

Petite erreur jouant un message d'occupation à l'appelant que j'ai pu constater depuis migration vers PJSIP.

3 appels par jours aboutissent à cette situation. (faible volume global)

Malgré étude, je ne comprend pas ce qu'est ce "Template aor autocreate" (https://www.asterisk.org/identifying-endpoint-pjsip/)

[Aug 17 17:07:21] WARNING[3734041]: res_pjsip_endpoint_identifier_autocreate.c:66 create_aor: Template aor 'autocreate' not found
[Aug 17 17:07:21] NOTICE[3734041]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'INVITE' from ' *"numentrant"* <sip: *"numentrant"* @38.b2bua.sip.internal>' failed for '"IPdutrunk:5060' (callid: 6db55ea35ff335360daabcb164a3d7a4@38.b2bua.sip.internal) - No matching endpoint found
[Aug 17 17:07:21] WARNING[803942]: res_pjsip_endpoint_identifier_autocreate.c:66 create_aor: Template aor 'autocreate' not found

Bonjour Antoine,

Content que la migration se soit plutôt bien passée !

Normalement, lors de l'upgrade les peers "autoprov" sont créés par le script 50_create_pjsip_autoprov_peers en post-start.d de l'upgrade. Je pense qu'il y'a eu un soucis lors de la migration car on a du perdre la conf de certains postes en autoprov et donc ils n'arrivent plus à s'enregistrer.

Le plus simple, sur le xivo:

• stopper fail2ban (/etc/init.d/fail2ban stop)
• supprimer les peers en autoprov dans la webi
• faire redémarrer les postes en autoprov
• Remettre le fail2ban ;) ( /etc/init.d/fail2ban start)

Bonjour Laurent et merci de ce retour.

Étonnamment, j'ai bien "tous mes petits", dans le fichier /etc/asterisk/pjsip.d/01-pjsip.conf

Pour chacun de mes anciens peers, j'ai un "aor", un "auth", et un "endpoint".

Le phénomène semble se produire uniquement pour des appels entrants, et aléatoirement.

Je vais monitorer un peu plus et je tenterais de refaire un autoprov comme conseillé.

Pour ceux qui feraient la migration également, si vous aviez modifié la variable définissant la durée de la session des clients, elle a été modifiée.
Ça n'est pas dans la doc d'upgrade, bien que l'updater invite clairement à comparer les fichiers remplacés. (vraiment top cet avertissement avec backup de l'ancien)

AUTH_EXPIRES=3600

est devenu :

AUTH_CTI_EXPIRES=3600
AUTH_WEBSERVICE_EXPIRES=86400

Je viens de tomber sur ce paramètre dans la config SIP globale :

autocreatepeer : Persist (persistent ?)

Autant il est dangereux de le laisser à "Yes", mais "persistent" ne me parlait pas :

https://www.voip-info.org/asterisk-sip-autocreatepeer/

A new setting for autocreatepeer ( autocreatepeer=persistent ) allows peers created using that setting to not be removed during SIP reload.

Il est sensé être obsolète, peut il y avoir un lien ?

En effet, c'est un oubli de feu chan_sip, ce paramètre n'est juste pas pris en compte. Je ne pense pas que ça soit la source du problème ici, enfin je n'espère pas....

J'ai eu la chance de tomber à un moment où le problème se produisait en monitorant de façon active.

Le message noté plus haut apparait sur un appel entrant, j'essaie donc moi même d'appeler, et j'ai un message vocal d'occupation de la part de Xivo + même message dans les logs.

Quand je check l'enregistrement du trunk, il est toujours OK (exp 50s / 120 s)

Pendant les 50s restantes, toutes mes tentatives d'appels échouent avec les même logs.

Une fois les 50 secondes passés, l'enregistrement est relancé et mes appels passent à nouveau sans problème.

C'est donc lié à l'enregistrement.

Sachant que je suis chez KEYYO et que le paramètre "match" de la section identify est un domaine (keyyo.net), est il possible que l'IP provenant du paquet reçu (INVITE failed no matching endpoint) soit comparé aux IP provenant d'une liste retenue par Asterisk lors de la dernière résolution de keyyo.net qui ne serait pas à jour ?

[KEYYO]
type = identify
endpoint = KEYYO
match = keyyo.net

A priori, petit soucis avec le xivo-switchboard-report aussi qui ne fonctionne plus. Les logs indiquent une impossibilité d'accéder à la BDD.

2023-08-23 16:48:08,299 -2023.05.00- 51577 INFO  r.Configuration- Initializing connection to the database
2023-08-23 16:48:08,299 -2023.05.00- 51577 INFO  r.ConnectionFactory- Initializing the database connection
2023-08-23 16:48:08,299 -2023.05.00- 51577 INFO  c.z.h.HikariDataSource- HikariPool-26 - Starting...
2023-08-23 16:48:09,300 -2023.05.00- 52578 ERROR c.z.h.p.HikariPool- HikariPool-26 - Exception during pool initialization.
org.postgresql.util.PSQLException: Connection to 172.18.0.1:5443 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
        at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:303)
        at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:51)
        at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:223)
        at org.postgresql.Driver.makeConnection(Driver.java:465)
        at org.postgresql.Driver.connect(Driver.java:264)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
2023-08-23 16:48:09,300 -2023.05.00- 52578 ERROR r.Configuration- Unable to get connection

Le fichier de conf pg_hba.conf autorise bien le réseau docker 172.18.0.0/24, mais ce n'est pas sensé être 5433 (et non 5443) le port d'écoute de postgresql ?

Ceci explique cela.

le container pgxivocc a été DROP et son param supprimé, mais la redirection de port avec, et xivo_stats l'utilisait.

https://gitlab.com/xivo.solutions/xivo-switchboard-reports/-/blob/2023.05/src/main/resources/application.conf?ref_type=heads

Je n'ai pas spécifié, mais l'upgrade a été testé sur un environnement UC Addon

Oups,

En effet nous avons simplifié l'UC addon pour ne plus avoir deux instances de postgreSQL mais plus qu'une mutualisée.

Par contre, on est complètement passé à coté du port utilisé pour le switchboard report qui est malheureusement hardcodé en 5443 de l'ancienne instance.....

J'ouvre un ticket pour être fixé en Kuma et +.

Merci encore pour ce retour, et désolé du dérangement !