Oui, en ce qui me concerne et pour des usages M2M avec ~5-10GB/mois de traffic, une SIM Sosh à 10 euros/mois fait très bien l'affaire.
Mais en effet je n'ai pas besoin des services en plus qu'on trouve sur les offres pro, et je suis *loin* d'avoir le volume nécessaire pour pouvoir négocier une remise. J'ai par contre besoin d'IPv6, et là, rien sur le M2M étrangement.

Le problème, c’est qu’on obtient finalement un aperçu automatique des pièces jointes, alors qu’on ne devrait avoir que de simples liens

Ça fonctionne avec les anciens formats d'images, c'est pour ça que j'avais tenté avec mon image WebP... sauf qu'avec ce format ce n'est jamais un aperçu, mais directement l'image à sa taille uploadée (je suppose que le même bug existe pour AVIF dans ce forum).

Avec plus de 2100px de largeur, ça commence à faire scroller du monde.
En 2K 100%, c'était déjà un peu mon cas.

Vivien a trouvé une autre astuce pour que ce ne soit plus le cas... mais non merci de mon côté pour la mise en place.

(Edit de 15h56: sur l'autre sujet, mon image est en fait légèrement réduite en auto de mon côté, mais c'est lisible sans agrandir, sauf que j'ai un sérieux doute pour ceux en full HD)

Par contre, avec un hébergeur externe, pour ce cas précis de trop de largeur, il m'a filé une astuce par mp, que je remets ici en le complétant pour qu'on puisse aussi cliquer pour agrandir. Imposer une largeur fixe à l'affichage (je ne sais pas/plus qu'on pouvais faire ça avec ces balises de forum):
[url=https://lafibre.info/images/logo/logo_creation_cle_usb_bootable.avif][img width=758]https://lafibre.info/images/logo/logo_creation_cle_usb_bootable.avif[/img][/url]Le chiffre pour width est à changer selon le contenu de l'image et le degrés d'universalité de l'affichage sans scrolling.
Ça évite déjà de créer une miniature par nous-même, dans certains cas.
J'ai tendance à mettre plus ou moins 900 quand il y a trop de détails/textes pour une miniature.

Bon, encore des déboires ahah.

Cette fois, j'ai la redirection de ports qui ne se fait pas correctement : on dirait que le tunnel fonction partiellement (oui ça n'a pas de sens)
J'ai passé plus d'une journée sur le truc sans suspecter OMR...

J'ai finit par mettre mon serveur juste derrière omr, avec des regles et une ip cible. Mes serveurs répondent sans repondre (j'ai internet, mais c'ets comme si les serveurs ne savaient pas s'authentifier).
J'ai baissé la mtu, même chose.

Je finis par mettre un bypass dans les source (omr) + changement de la zone uniquement dans les regles nat (de zone vpn à wan évidement) : les serveurs sont parfaitement enfin joignables depuis les wans...
J'enlève le bypass + repassage des zones en zone vpn, le serveur répond à moitié avec l'ip vps.
Le vps n'a pas de parefeu externe (host) ni interne (linux) autre que ce qui est géré par OMR.

Je constate (merci l'ia) qu'il y a un soucis avec le peer : le vps a un peer en 3 ou 4, et la vm est en 2 par exemple.
Je redémarre l'un, l'autre, et toujours des différences.
J'ai tenté de relancer le script aussi. Même constat.
Là, après avoir remis mqvpn, je n'arrive même plus à me connecter à la vm locale en ssh ou web...

J'ai tenté mqvpn et glorytun udp... avec mqvpn y'a pas d'affichage tout court des serveurs (j'avais commencé par là d'ailleurs, en config @stock).

Bref, j'abandonne à nouveau OMR, et je vais refaire de l'ip6ip6 et ip4ip6...

VPS debian 13 pulseheberge, vm debian 13 sous proxmox.
Les autres omr semblent bien fonctionner (une qui était en glory et l'autre mqvpn, mais je ne sais pas pourquoi/comment s'est fait la config). Une chez sapinet et une chez ionos (vps).

Question bête... Ayant lu que le problème d'hébergement de la partie semblait sensible, est-ce que la même IP peut être serveur et client en même temps dans ce type de jeu (par ex: Grounded)?

Complément pour ceux qui veulent un Asterisk sur un serveur du LAN, et non sur le routeur (cas de farmouss, kdaffef91, olitask... resté sans solution publiée ici). Configuration en service depuis fin septembre 2026 : Asterisk 22 (PJSIP) sur un NAS Debian, derrière un Xiaomi AX3000T sous OpenWrt branché sur l'ONT, NB6VAC éteinte. Entrants, sortants, présentation du numéro, DTMF, urgences.

Prérequis : une IPv4 publique dédiée (pas de CGNAT, sinon aucune redirection possible, voir plus haut dans le fil) et fixe, puisqu'elle est écrite dans la configuration.

1. Routeur OpenWrt : deux redirections vers le serveur, MÊMES ports des deux côtés (Asterisk annonce ses ports tels quels ; une translation de port casse l'audio). Pas d'ALG SIP.

config redirect
option name 'SIP-SFR'
option src 'wan'
option dest 'lan'
option proto 'udp'
option src_dport '5062'
option dest_ip '192.168.1.X'
option dest_port '5062'
option target 'DNAT'
option reflection '0'
option src_ip '92.91.129.136'

(même bloc quatre fois de plus, avec src_ip 92.91.129.152, .168, .184 et .200)

config redirect
option name 'RTP-SFR'
option src 'wan'
option dest 'lan'
option proto 'udp'
option src_dport '20000-20099'
option dest_ip '192.168.1.X'
option dest_port '20000-20099'
option target 'DNAT'
option reflection '0'

Les cinq adresses sont celles de trappes.p-cscf.sfr.net (getent ahostsv4 trappes.p-cscf.sfr.net). Une redirection par adresse : je n'ai pas vérifié qu'une seule redirection avec une liste src_ip soit respectée par fw4. Vérifier après coup avec nft list chain inet fw4 dstnat_wan que chaque règle SIP-SFR porte bien son ip saddr. Le RTP reste sans restriction : les passerelles média de SFR ne sont pas connues d'avance. Le routeur conserve le port source 5062 en sortie (vérifié dans conntrack).

Constat intéressant : les compteurs des cinq règles SIP sont à 0 depuis le dernier redémarrage du routeur, alors que des appels entrants sont arrivés depuis. Les INVITE de SFR passent donc par la correspondance NAT que maintiennent les REGISTER et les OPTIONS sortants depuis le port 5062, et non par la redirection, qui ne sert qu'en secours. Ça va dans le sens du rôle des OPTIONS décrit plus bas, sans le démontrer.

2. rtp.conf

[general]
rtpstart = 20000
rtpend = 20099
strictrtp = yes

3. pjsip.conf (numéro, NDI et mot de passe remplacés)

[transport-sfr]
type = transport
protocol = udp
bind = 0.0.0.0:5062
external_signaling_address = <IP publique>
external_signaling_port = 5062
external_media_address = <IP publique>
local_net = 192.168.1.0/24

[sfr-auth]
type = auth
auth_type = digest
username = NDI...@sfr.fr
password = <mot de passe SIP>

[sfr]
type = registration
transport = transport-sfr
outbound_auth = sfr-auth
server_uri = sip:ims.mnc010.mcc208.3gppnetwork.org
client_uri = sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org
contact_user = +33XXXXXXXXX
outbound_proxy = sip:92.91.129.168:5062\;lr
expiration = 3600
retry_interval = 60
max_retries = 10000
forbidden_retry_interval = 600
fatal_retry_interval = 600
auth_rejection_permanent = no

[sfr]
type = endpoint
transport = transport-sfr
context = depuis-sfr
disallow = all
allow = alaw,ulaw
dtmf_mode = rfc4733
direct_media = no
outbound_auth = sfr-auth
outbound_proxy = sip:92.91.129.168:5062\;lr
from_domain = ims.mnc010.mcc208.3gppnetwork.org
from_user = +33XXXXXXXXX
aors = sfr
rewrite_contact = yes
100rel = yes
rtp_symmetric = yes
force_rport = yes
trust_id_inbound = yes

[sfr]
type = aor
contact = sip:ims.mnc010.mcc208.3gppnetwork.org
outbound_proxy = sip:92.91.129.168:5062\;lr
qualify_frequency = 60

[sfr]
type = identify
endpoint = sfr
match = 92.91.129.136
match = 92.91.129.152
match = 92.91.129.168
match = 92.91.129.184
match = 92.91.129.200

4. Sortants, dans extensions.conf : donner l'URI explicitement (les urgences 15, 17, 18, 112... de la même façon).

exten => _0XXXXXXXXX,1,Dial(PJSIP/sfr/sip:${EXTEN}@ims.mnc010.mcc208.3gppnetwork.org,120)

Deux pièges propres au cas « derrière NAT », qui m'ont coûté deux semaines (détail dans mon fil : https://lafibre.info/remplacer-sfr/asteriskopenwrt-entrants-perdus-apres-inactivite-ok-apres-un-sortant/) :

- Sans la qualification OPTIONS de l'AOR (qualify_frequency = 60, avec l'outbound_proxy répété DANS l'AOR, celui de l'endpoint ne vaut pas pour les OPTIONS), les appels entrants cessaient d'arriver après quelques heures sans communication, alors que l'inscription restait active. Avec : cinq silences de 6 h à 28 h tenus sans perte.

- Avec la qualification, si le proxy ne répond plus aux OPTIONS pendant quelques minutes, le contact passe Unavailable et la forme habituelle Dial(PJSIP/${EXTEN}@sfr) refuse localement TOUS les sortants, urgences comprises (« cause 3 - No route to destination »). L'URI explicite du point 4 contourne ce blocage : vérifié en forçant le contact Unavailable.