La Fibre
Datacenter et équipements réseaux => Routeurs => 
Téléphonie VoIP / SIP => Discussion démarrée par: alex38 le 24 mai 2023 à 18:29:39
-
Bonjour,
Je sèche depuis quelque temps sur l'utilisation du SIP avec SFR.
J'ai beau modifier de nombreux paramètres de mon cisco SPA112, mes appels sortant coupent au bout de 32 secondes (oui c'est précis).
Côté appels entrants, je n'ai aucun problème, cela signifie donc que mon paramétrage "global" est correct.
J'ai lui sur pas mal de forum qu'il y avait des modifications à faire côté paramétrage NAT, installation de SIProxy, désactivation de SIP-ALG, forcer le codec 77u, etc..
J'ai essayé pas mal de choses sur mon routeur sans succès. Je précise que je suis en full IPv4
Ce qui est plus étonnant, c'est que j'ai installé le logiciel Zoiper sur mon téléphone, donc dans ce cas, je ne passe plus par le cisco, ni par mon routeur, et quand je suis connecté en 4G (donc pas en Wifi pour ne pas dépendre de mon routeur), les appels sortant coupent également au bout de ces 32 secondes. J'en déduit que le problème est ailleurs...
Cela voudrait donc dire que c'est l'un des paramètre qui n'est pas correct mais lequel ?
Si vous avez un paramétrage CISCO SPA112 complet qui fonctionne avec SFR, des règles de firewall éventuelles ou une idée de diagnostic, je suis preneur...
-
Idée de test : en re-branchant la NeufBox sur l'ONT, est-ce que les appels SIP sont encore coupés après 32s (depuis les divers terminaux SIP à disposition) ?
-
Bonjour,
Merci pour le conseil.
J'ai finalement réinitialisé le SPA112 avec les paramètres d'usine et j'ai appliqué les paramétrages du premier post et cela marche...en partie.
Je n'ai plus de coupures au bout de 32 secondes !!
Mais maintenant, il arrive que je ne sois pas joignable ou que quand je fais un appel, cela sonne occupé alors que le correspondant est pourtant disponible.
J'ai fait des backup de configuraiton et je vais essayer de mieux comprendre quels sont les critères qui posent des problemes.
Je soupçonne que le outbound proxy et les paramètres associés soient les fautifs. J'ai finalement mis "residential...."
-
Ça me rappelle mon cas quand je découvrais les joies de la VoIP avec asterisk.
Le plus souvent le fautif est le NAT, le fait que tu sois injoignable est un des symptômes (la connexion retour se referme). Moins y'a de NAT sur le trajet mieux c'est. Perso, j'ai foutu un VPN entre mes périphs et asterisk et j'ai bien moins de soucis depuis. Je n'ai que la partie serveur à gérer pour la connexion avec OVH.
Essaies dans un premier temps de paramétrer un keepalive court genre 10-15sec. En 4G pour ne pas avoir de problème, il faut le mettre à 5 sec.
-
Salut à tous.
Que j'utilise MicroSIP depuis windows 10 Pro connecté à ma Box SFR ou bien Zoiper5 depuis Debian Bullseye branché directement sur l'ONT SFR, j'ai une perte de la connexion sortante au bout des 30 secondes. J'aimerai savoir si vous avez résolu votre problème ?
Pour palier à cet inconvénient, dois je installer Asterisk ?
Cordialement.
Artemus24
@+
-
Cela ressemble à un problème de SIP ALG. Trouves-tu un paramètre similaire sur ton routeur ? Essaies en le désactivant
-
Cela ressemble à un problème de SIP ALG. Trouves-tu un paramètre similaire sur ton routeur ? Essaies en le désactivant
Je me demande pourquoi les constructeurs continuent à activer ces ALG par défaut. Ca ne pose que des soucis...
-
Une perte de com au bout de x secondes, c'est la perte de la session UDP dans la table NAT du routeur. (du coup il ne sait plus où doivent aller les paquets sur le chemin du retour, dans le sens Internet->votre tel).
Etant donné qu'UDP n'a pas de notion de session, le routeur doit maintenir une table hypothétique sur chaque communication UDP avec une limite horaire arbitraire.
Ca peut être à la fois très très court comme une requête DNS (qui dure moins d'une seconde), comme très long (maintenir un appel sur 1h).
Du coup on fait quoi ? On laisse toutes les "sessions" UDP pendant 1h (au risque que les requêtes DNS saturent la table et écrase d'autres sessions) ?
Voilà pourquoi il est utile d'avoir du NAT keepalive pour maintenir cette session active aux yeux du routeur, lui dire que la session est encore utilisée et donc qu'il ne doit pas la couper.
Ou faire comme nous : utiliser IPv6 :)
Aucune comm blanche garantie 8)
-
Cela ressemble à un problème de SIP ALG. Trouves-tu un paramètre similaire sur ton routeur ? Essaies en le désactivant
Sous Windows, donc avec la Box SFR, le SIP ALG est désactivé.
Sous Debian, je n'ai pas de routeur puisque je suis branché directement sur l'ONT.
]Voilà pourquoi il est utile d'avoir du NAT keepalive pour maintenir cette session active aux yeux du routeur, lui dire que la session est encore utilisée et donc qu'il ne doit pas la couper.
J'ignore où activer le "NAT keepalive" dont vous parlez.
Dans MicroSIP, j'ai le même problème si je mets "Transport : TCP" ou "TCP+UDP". J'ai coché "Désactiver les minuteurs de session".
Dans Zoiper5, J'ai bien une zone "keepalive" qui est configuré à 30 secondes. Elle n'a aucun effet au problème.
Est-ce qu'en installant Asterisk, je vais résoudre mon problème des 30 secondes ?
Ou faire comme nous : utiliser IPv6 :)
Mais je suis en IPv6. :-\
-
bonjour
quand vous évoquez les appels sip sortants, c'est avec un fournisseur tiers (pas sfr) derrière une box sfr?
ou c'est sfr qui vous fournit la possibilité d'avoir votre numéro de tel abonné, sur un client sip de votre choix?
j'ai pas trouvé cette précision, mais le second cas serait très étonnant..
-
J'utilise les informations VOIP/SIP de SFR que j'ai pu récupérer grâce à l'application de NextGens.
Mon but est d'installer un routeur à la place de ma Box SFR et de conserver le Triple Play.
Je sais récupérer les adresses IPv4 & IPv6 derrière l'ONT SFR, mais je cherche encore une solution pour la téléphonie.
-
Une perte de com au bout de x secondes, c'est la perte de la session UDP dans la table NAT du routeur. (du coup il ne sait plus où doivent aller les paquets sur le chemin du retour, dans le sens Internet->votre tel).
Etant donné qu'UDP n'a pas de notion de session, le routeur doit maintenir une table hypothétique sur chaque communication UDP avec une limite horaire arbitraire.
Ca peut être à la fois très très court comme une requête DNS (qui dure moins d'une seconde), comme très long (maintenir un appel sur 1h).
Du coup on fait quoi ? On laisse toutes les "sessions" UDP pendant 1h (au risque que les requêtes DNS saturent la table et écrase d'autres sessions) ?
Voilà pourquoi il est utile d'avoir du NAT keepalive pour maintenir cette session active aux yeux du routeur, lui dire que la session est encore utilisée et donc qu'il ne doit pas la couper.
Ou faire comme nous : utiliser IPv6 :)
Aucune comm blanche garantie 8)
Merci pour cette superbe explication !
du coup mes recherches m'ont menné aux parametres du fichier /etc/sysctl.d/11-nf-conntrack.conf sur openwrt
# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings
net.netfilter.nf_conntrack_acct=1
net.netfilter.nf_conntrack_checksum=0
net.netfilter.nf_conntrack_tcp_timeout_established=7440
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180
Je vois bien pour UDP et TCP des parametres de timeout mais ils sont supérieurs aux 30 sec...
par contre je ne vois pas de net.netfilter.nf_conntrack_udp_timeout_established, probablement que ca n'existe pas ;D
je vais creuser dès que je trouve 5 min ;)
-
par contre je ne vois pas de net.netfilter.nf_conntrack_udp_timeout_established, probablement que ca n'existe pas ;D
je vais creuser dès que je trouve 5 min ;)
C'est exact, car UDP n'a pas de notion de session. Donc les "new", "related", "established" etc, n'existent pas en UDP :)
Voilà pourquoi le timeout des sessions TCP dure bcp plus longtemps, car on s'attend à avoir un "stop" à un moment pour la fermer proprement (très souvent avant tes 7440sec).
Mais tu brules. Pendant un appel, faut surveiller son conntrack :)
-
@artemus24
de ton côté il faut regarder par ici : https://blog.wirelessmoves.com/2015/06/udp-nat-timeouts-and-how-to-change-them.html
-
Mais tu brules. Pendant un appel, faut surveiller son conntrack :)
Alors j'ai cru comprendre qu'il fallait desactiver le conntrack pour eviter les sip_alg ? du coup j'avais dans : /etc/sysctl.conf
la ligne net.netfilter.nf_conntrack_helper=1
que j'ai passé à 0, mais ca ne marche pas mieux...donc 0 ou 1 chez moi ca ne change rien. la vérité est ailleurs ;D je cherche...
EDIT:
j'ai trouvé ce post assez récent: https://forum.fongo.com/viewtopic.php?f=8&t=20534#p80567
g. OpenWrt
Add the following (or change) to /etc/sysctl.conf
i) net.netfilter.nf_conntrack_udp_timeout_stream=115 if the failed registration retry timer (RegisterRetryInterval) in your ATA or IP Phone is 120 seconds for Freephoneline.
ii) net.netfilter.nf_conntrack_udp_timeout=15 if the NAT Keep-alive Interval (X_KeepAliveExpires) in your ATA or IP Phone is 20 seconds for Freephoneline
Then run sysctl -p to load the new settings from the file.j'ai fait mais ca n'a rien changé :o
-
Merci Rooot :) Je n'ai pas de "netfilter" dans le répertoire "/proc/sys/net/ipv4" ou "/proc/sys/net/ipv6" sous Debian. Que dois-je faire ?
Pourquoi parles-vous de l'UDP alors que mon Zoiper5 utilise le transport TCP ?
Désolé de le dire, mais je suis largué. :(
-
Merci Rooot :) Je n'ai pas de "netfilter" dans le répertoire "/proc/sys/net/ipv4" ou "/proc/sys/net/ipv6" sous Debian. Que dois-je faire ?
Pourquoi parles-vous de l'UDP alors que mon Zoiper5 utilise le transport TCP ?
Désolé de le dire, mais je suis largué. :(
je pense que c'est de l'udp quand meme, je sais pas pourquoi Zoiper indique TCP...
Sinon regarde avec ce chemin : /proc/sys/net/netfilter/nf_conntrack_udp_timeout
chez moi :
(https://i.imgur.com/yAhP60p.png)
-
root~> cd /proc/sys/net
root/proc/sys/net> ls
core ipv4 ipv6 netfilter unix
root/proc/sys/net> cd netfilter
root/proc/sys/net/netfilter> la
total 0
dr-xr-xr-x 1 root root 0 9 août 17:48 .
dr-xr-xr-x 1 root root 0 9 août 17:37 ..
dr-xr-xr-x 1 root root 0 9 août 18:32 nf_log
-rw-r--r-- 1 root root 0 9 août 18:32 nf_log_all_netns
root/proc/sys/net/netfilter>
-
J'utilise les informations VOIP/SIP de SFR que j'ai pu récupérer grâce à l'application de nextgen.
Mon but est d'installer un routeur à la place de ma Box SFR et de conserver le Triple Play.
Je sais récupérer les adresses IPv4 & IPv6 derrière l'ONT SFR, mais je cherche encore une solution pour la téléphonie.
effectivement, cela m'étonne que ce soit accessible : si quelqu'un peut confirmer qu'orange l'a toujours refusé, (je sais pas pour byg) et que free l'a justement fermé (le service sip) ; ca permettrait quelque part, à l'étranger, de passer des coups de fil avec un client sip via wifi, sans s'affranchir d'un hors forfait en itinérance?
-
Je précise que c'est le service téléphonique normal de SFR, c'est-à-dire la ligne téléphonique que j'ai depuis que je suis chez SFR, et non LiberTalk qui a été fermé en janvier 2017.
Ce que je ne comprends pas en lisant les sujet similaires consacré à la téléphonie SFR, certains n'ont aucun problème. Je prends le cas du sujet de MaximusHugus (https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/msg685736/#msg685736) où il installe asterisk dans un routeur OpenWrt, et tout semble fonctionner normalement. Est-ce qu'Asterisk va résoudre ce problème ? Peut-on me le confirmer, svp ?
Si ce problème est lié à la VOIP/SIP, cela aurait dû être géré par le SoftPhone, non ?
J'ai du mal à comprendre pourquoi le problème est lié à l'UDP.
-
aucune idée...
est-ce que chez toi avec microsip les appels entrants (mobile vers microsip) coupent au bout de 30s ? ce qui n'est pas le cas chez moi.
-
Concernent asterisk, c’est pas évident du tout à configurer et les tuto concernent des anciennes versions.
Perso,j’ai eu beucoup d’erreurs et j’ai fini par laisser tomber.
Moi je fonctionne avec un SPA112 mais j’ai des problèmes de lignes occupées de temps en temps.
J’ai fait un bypass de mon routeur sfr que j’ai remplacé par un ax3600 en openwrt.
-
J’ai fait un bypass de mon routeur sfr que j’ai remplacé par un ax3600 en openwrt.
et aucun parametrage particulier au niveau de firewall etc ??
-
est-ce que chez toi avec microsip les appels entrants (mobile vers microsip) coupent au bout de 30s ? ce qui n'est pas le cas chez moi.
J'utilise MicroSIP sous Windows avec la Box SFR. La Box bloque les appels entrants, même si je désactive le téléphone dans "éco". "SIG ALP" est désactivé. J'utilise Zoiper5 sous Debian branché sur l'ONT, donc sans routeur. Je n'ai aucun problème avec les appels entrants.
Ce sont juste des tests. En temps normal, mon Gigaset A545A est branché sur la Box SFR.
Moi je fonctionne avec un SPA112 mais j’ai des problèmes de lignes occupées de temps en temps.
J'ai pensé faire comme chez OVH, me procurer un boitier Cisco ATA 191 ou 192. Je pense que j'aurai les mêmes problèmes avec mon Gigaset A545A DECT, à savoir une mauvaise qualité audio. Je ne cherche pas à faire de l'itinérance, juste à conserver la téléphonie quand j'aurai un nouveau routeur. J'ai plus besoin d'être contacté que d'appeler.
Pour une meilleur qualité audio, je préfère avoir un téléphone VOIP/SIP, genre Gigaset DECT pouvant gérer deux SIP. Qu'est-ce que vous me conseillez ?
-
je viens de tester Bria et je n'ai pas de coupure...mais je n'ai pas de son >:(
https://www.counterpath.com/plan-select-solo/
j'ai configuré comme ceci :
(https://i.imgur.com/R430JzH.png)
(https://i.imgur.com/5JOQHvM.png)
Pour Firewall Method, j'ai essayé STUN et ICE, et pas de coupure dans les 2 cas, mais pas de son non plus. Je ne vois pas ce que j'ai raté...
-
Je précise que c'est le service téléphonique normal de SFR, c'est-à-dire la ligne téléphonique que j'ai depuis que je suis chez SFR, et non LiberTalk qui a été fermé en janvier 2017.
Ce que je ne comprends pas en lisant les sujet similaires consacré à la téléphonie SFR, certains n'ont aucun problème. Je prends le cas du sujet de MaximusHugus (https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/msg685736/#msg685736) où il installe asterisk dans un routeur OpenWrt, et tout semble fonctionner normalement. Est-ce qu'Asterisk va résoudre ce problème ? Peut-on me le confirmer, svp ?
Si ce problème est lié à la VOIP/SIP, cela aurait dû être géré par le SoftPhone, non ?
J'ai du mal à comprendre pourquoi le problème est lié à l'UDP.
Concernent asterisk, c’est pas évident du tout à configurer et les tuto concernent des anciennes versions.
Perso,j’ai eu beucoup d’erreurs et j’ai fini par laisser tomber.
Moi je fonctionne avec un SPA112 mais j’ai des problèmes de lignes occupées de temps en temps.
J’ai fait un bypass de mon routeur sfr que j’ai remplacé par un ax3600 en openwrt.
libertalk devait être la "roue de secours" de sfr, pour équilibrer les oprateurs : world and you chez byg, freephonie chez free ou libon chez orange.. tous ont fermé depuis (sauf libon), et me semble, permettaient de passer des appels "comme en france" (donc sans surcout d'itinérance à l'étranger) en utilisant une appli, de n'importe où dans le monde (une sorte de voip)
je m'interroge, sur le fait qu'avoir un client sip pour réceptionner les appels sur son numéro géographique (ou 09) puisse être réalisable, hors de chez soi, hors de france ou hors d'europe?
-
@ trekker : à partir du moment où le FAI utilise la VOIP/SIP, la téléphonie est accessible depuis n'importe où dans le monde. L'application dont tu parles est un SoftPhone, comme Zoiper5, MicroSIP ou Linephone. Il en existe d'autres. Je ne suis pas en 09 mais en 05, puisque je réside dans la Nouvelle Aquitaine. Si je prends un service de téléphonie VOIP/SIP professionnel, il est fort probable que j'aurai un 09, comme celui de chez OVH. C'est le même fonctionnement, je crois, que Skype. La seule différence est l'encapsulation faite par le FAI pour nous facturer le service alors que c'est gratuit puisque ça transite par l'internet.
C'est pourquoi, le numéro de téléphone doit être au format international. On remplace le zéro du début par 0033 ou par +33.
J'ai constaté par mes tests, qu'aucune facturation n'a été faite sur ma ligne téléphonique. Comme je n'ai pas de téléphone mobile, il m'est difficile de savoir si la communication vers celui-ci est identifié par SFR. Je suppose que pour l'international, cela doit être pareil, aucune identification. Mon problème est que je ne connais personne à l'étranger pour faire ce test.
@ Rooot : je vais essayer d'installer Asterisk dans mon Debian et faire le test.
-
@ trekker : à partir du moment où le FAI utilise la VOIP/SIP, la téléphonie est accessible depuis n'importe où dans le monde. L'application dont tu parles est un SoftPhone, comme Zoiper5, MicroSIP ou Linephone. Il en existe d'autres. Je ne suis pas en 09 mais en 05, puisque je réside dans la Nouvelle Aquitaine. Si je prends un service de téléphonie VOIP/SIP professionnel, il est fort probable que j'aurai un 09, comme celui de chez OVH. C'est le même fonctionnement, je crois, que Skype. La seule différence est l'encapsulation faite par le FAI pour nous facturer le service alors que c'est gratuit puisque ça transite par l'internet.
C'est pourquoi, le numéro de téléphone doit être au format international. On remplace le zéro du début par 0033 ou par +33.
J'ai constaté par mes tests, qu'aucune facturation n'a été faite sur ma ligne téléphonique. Comme je n'ai pas de téléphone mobile, il m'est difficile de savoir si la communication vers celui-ci est identifié par SFR. Je suppose que pour l'international, cela doit être pareil, aucune identification. Mon problème est que je ne connais personne à l'étranger pour faire ce test.
le simple fait d'avoir un client/appli sip avec son numéro géographique, je sais pas ce qu'en pensent nos experts, sur autre chose que son tel fixe en bout de box, est quelque chose qui pour moi reste plus qu'exotique, dans le sens où les opés sont souvent vent deboout contre ces pratiques, sous prétexte de faciliter le piratage et les abus de conso téléphonique...
si tu peux éventuellement vérifier qu'hors de chez toi, sur un acces internet non sfr, ca fonctionne.... c'est très surprenant d'avoir cette "découverte" qui fasse si ppeu de bruit, alors que la fermeture des services des trois autres avaient tellement fait couler d'encre...
-
Bon avec Bria, j'ai trouvé comment avoir le son, mais du coup je me retrouve encore limité aux 30s >:( . je n'arrive pas à comprendre le rapport.
En fait il suffit d'indiquer le serveur STUN de google dans Firewall.
(https://i.imgur.com/80JJj4q.png)
Dans sans STUN pas de coupure mais pas de son, avec STUN le son mais coupure a 30s.
-
je pense avoir trouvé la raison de la coupure prématurée de l'appel, Microsip ne semble pas savoir que l'on a décroché. j'ai fait une capture wireshark dans les 2 senses, appel Microsip et appel depuis un mobile.
Appel depuis un mobile vers Microsip, tout se passe bien :
(https://i.imgur.com/OKhm3jR.png)
Appel de Microsip vers un mobile :
(https://i.imgur.com/N7F3ai8.png)
-
Je me suis demandé pourquoi ces 32 secondes dans le titre de ce sujet. En bidouillant avec Asterix, Zoiper 5 interrompt l'appel (et non la communication qui ne s'est pas faite) exactement au bout des 32 secondes. Il y a bien un timer qui doit contrôler cela car c'est trop précis comme durée.
J'ai cru que le problème venait du serveur STUN, alors je l'ai changé mais le problème persiste. On peut ne pas l'utiliser et avoir quand même cette interruption. Même problème si le transport passe en TCP.
Je pense qu'il doit y avoir une différence dans le comportement de la téléphonie SFR où depuis un SoftPhone, il manque un paramétrage pour pallier cet inconvénient. C'est déjà bien de savoir que la communication entrante ne rencontre pas ce problème. D'où mon interrogation concernant un téléphone VOIP/SIP. Est-ce que la communication sortante sera interrompue de la même façon ou pas ?
J'ai installé sous Debian Asterisk Si je passe par les entrepots Debian, la version est 16.18.0. J'ai préféré prendre la dernière version 20.4.0. Pour l'installation, j'ai suivi ce didacticiel (https://computingforgeeks.com/install-asterisk-lts-on-debian-linux/). A priori, le service est opérationnel.
Pour le paramétrage, j'ai repris l'exemple donnée par MaximusHugus (https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/msg685736/#msg685736). J'ai fait mes tests avec l'Asus branché sur l'ONT mais j'avais trop de "notify", ce qui m'empêchait d'utiliser correctement "Asterisk Client". Je me suis branché sur ma Box SFR, et je n'ai plus eu ces "notify". Je vois bien les messages dans "Asterisk Client" quand je fais une tentative par Zoiper5, mais je n'ai pas de connexion. Je vais continuer mes investigations.
Bria, je ne peux pas l'utiliser car je ne suis pas dans OpenWrt, mais sous Debian.
je pense avoir trouvé la raison de la coupure prématurée de l'appel, Microsip ne semble pas savoir que l'on a décroché.
Pourtant, la communication se fait.
Si je prends la différence de temps entre le début et la fin de "183: session Progress", nous avons :
--> 35,407003 - 3,315852
--> 32,091151.
On retrouve ces 32 secondes, ce qui voudrait dire que c'est MicroSIP ou Zoiper5 qui interrompt la communication.
Je constate dans Mobile vers MicroSIP, le SIP contient des informations qui ne sont pas présentes dans MicroSIP vers Mobile. Il se peut que la différence soit là. J'ai ajouté dans le "serveur SIP" : ":5062;transport=udp;ob", mais cela n'a rien changé.
Merci pour la récupération du flux par WireShark. Comment as tu procédé ? Entre l'ONT et le routeur, as tu fais un branchement particulier ?
C'est peut-être une sécurité mise en place par SFR pour éviter d'utiliser leur service téléphonie gratuitement.
-
Merci pour la récupération du flux par WireShark. Comment as tu procédé ? Entre l'ONT et le routeur, as tu fais un branchement particulier ?
les 2 captures ont été faites tout simplement sur mon PC. j'ai lancé la capture puis effectué les appels.
Dans cette capture on voit bien que c'est la source (SFR 92.91.179.72) qui envoie le "server internal error", ce n'est pas microsip qui coupe.
(https://i.imgur.com/N7F3ai8.png)
D'ailleurs Microsip reste toujours à l'ecoute et décide de couper beaucoup plus tard.
-
Au passage voici les réglages avec Microsip qui semblent plus corrects, d'après l'aide d'une personne du Forum Openwrt :
(https://i.imgur.com/0xn30x1.png) (https://i.imgur.com/f1aQRCF.png)
On notera 3 choses importantes :
Le SIP Proxy : residential.p-cscf.sfr.net
L'indication de l'adresse IP publique, puisqu'elle est "quasiment" fixe chez SFR donc inutile de passer par des mécanismes comme STUN.
l'Ajout des DNS SFR dans les paramettres généreaux, sur mon routeur j'utilise 1.1.1.1, pour permettre la résolution de residential.p-cscf.sfr.net
Pour "Source Port" on peut mettre n'importe quoi d'autre que 5060, 50600 par exemple fonctionne.
Mais malheureusement, ca coupe toujours...Les status RINGING et INVITE n'arrivent pas jusqu'a l'application.
-
Ne vous perdez pas les réglages et essayez de suivre la logique et le chemin des paquets.
Rooot, tu dis que les paquets n'arrivent pas jusqu'à l'application. Mais au moins, arrivent-ils sur la patte publique de ton routeur ? Faut déjà s'assurer de cela.
-
Ne vous perdez pas les réglages et essayez de suivre la logique et le chemin des paquets.
Rooot, tu dis que les paquets n'arrivent pas jusqu'à l'application. Mais au moins, arrivent-ils sur la patte publique de ton routeur ? Faut déjà s'assurer de cela.
Bien vu ! je viens de faire une capture depuis le routeur, et pas de status 180 Ringing et encore moins de 200 OK
(https://i.imgur.com/G1eDuim.png)
Et en parallele sur les requettes DNS capturées, puisque c'es de l'UDP, je vois ceci qui m'interpelle :
(https://i.imgur.com/1cXWbi0.png)
-
Ok. C'est déjà bon signe.
Maintenant pourquoi ça ne va pas de ta patte publique à ton application ?
Regarde si ton application ne forge pas des paquets avec l'IP publique en IP source. Car sinon ton routeur il forward bêtement vers l'extérieur, et il y aura un pb sur le retour.
Car oui, moi Optix, petit routeur de famille, je reçois un colis à mon adresse, mais qui a commandé ?
Donc il faut se concentrer sur la requête que TOI tu émets.
Soit tu laisses l'IP privée pour laisser le routeur et son NAT faire le job correctement sur le retour (ah oui, 192.168.0.13 m'avait envoyé un truc, là j'ai la réponse, je lui redonne).
Soit tu forges des paquets avec l'IP publique... mais en tenant compte que ton routeur ne saura pas le forward sur le retour (donc règle DST-NAT statique).
-
Regarde si ton application ne forge pas des paquets avec l'IP publique en IP source. Car sinon ton routeur il forward bêtement vers l'extérieur, et il y aura un pb sur le retour.
Car oui, moi Optix, petit routeur de famille, je reçois un colis à mon adresse, mais qui a commandé ?
Donc il faut se concentrer sur la requête que TOI tu émets.
a priori, s'il faut capturer le traffic depuis mon PC lorsque j'emet un appel, j'ai déjà ces captures là dans ce post :
https://lafibre.info/remplacer-sfr/red-by-sfr-appels-sip-sortant-coupes-au-bout-de-32-secondes/msg1028600/#msg1028600
Mon IP publique n'apparait a aucun moment.
-
Mon IP publique n'apparait a aucun moment.
Ok, donc déjà ça c'est bien : tu sors avec une IP privée, comme ça le NAT peut faire son job (càd réécrire tes paquets avec l'IP publique) et t'ajouter à son "conntrack" pour gérer le retour (réécrire avec ton IP privée et te forward la réponse).
Par contre, à l'intérieur même du colis, dans la requête SIP, qu'envoies-tu comme IP ? La publique ou la privée ? Cette partie, c'est effectivement le helper "SIP ALG" qui gère (ou non).
-
je suis pas certain que c'est là qu'il faut regarder mais, je dirais que c'est bien mon ip publique qui apparait dans le "colissimo" ;D
(https://i.imgur.com/VigxtvF.png)
-
Mhhh, j'ignore si le SIP ALG est coupé ou non sur ton routeur, car là il devrait voir que la requête qui part avec le port source 5060.
Par acquis de conscience, tu as forwardé le port 5060 vers ton IP privée ? Ou le forward si ce n'est pas le cas ?
-
ce serait pas une question d'outbound/proxy?
enfin je dis ca..
-
Bah le problème est déjà au niveau IP (et non applicatif) : pourquoi le routeur reçoit la réponse, mais pas son soft ?
Pour ça qu'il faut d'abord se concentrer sur la base au lieu de modifier 36000 options.
-
Mhhh, j'ignore si le SIP ALG est coupé ou non sur ton routeur, car là il devrait voir que la requête qui part avec le port source 5060.
Par acquis de conscience, tu as forwardé le port 5060 vers ton IP privée ? Ou le forward si ce n'est pas le cas ?
j'avais lu de droite et de gauche tout et son contraire a ce sujet. actuellement je n'ai pas de SIP ALG activé, ni port forwarding sur le 5060.
J'ai par ailleurs quand meme testé avec et sans, ca n'a rien changé au probleme.
J'ai testé le SIP passthrough d'openwrt : https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_nat#sip_passthrough
Bah le problème est déjà au niveau IP (et non applicatif) : pourquoi le routeur reçoit la réponse, mais pas son soft ?
ha ben non, dans les captures depuis le routeur, sur le WAN, j'ai pas non plus les status "180 RINGING" et "200 OK"...Donc ces 2 status là ne sont pas reçu au niveau du routeur. Mais est-ce que seulement ils sont envoyés ? ;D
Le serveur sait envoyer tous les autres status au bon endroit, et il ne saurait pas où envoyer les 180/200 ?
-
Bah le problème est déjà au niveau IP (et non applicatif) : pourquoi le routeur reçoit la réponse, mais pas son soft ?
Pour ça qu'il faut d'abord se concentrer sur la base au lieu de modifier 36000 options.
les proxy/outbound ne sont pas des options de second degré, loin de là..
-
les proxy/outbound ne sont pas des options de second degré, loin de là..
Je ne dis pas le contraire, mais là les paquets arrivent sur son WAN, mais visiblement son soft ne reçoit rien. Il faut déjà régler ça amha
Dixit l'intéressé :
Mais malheureusement, ca coupe toujours...Les status RINGING et INVITE n'arrivent pas jusqu'a l'application.
Si la couche IP (la couche basse) a déjà une merde, tu auras beau trifouiller sur la couche applicative au-dessus, le pb restera le même selon moi.
Du coup rooot, configure déjà une règle de forwarding (dst-nat) pour que les paquets qui arrivent sur ta patte publique, arrivent jusqu'à ton softphone. On verra s'il arrive à enchainer la suite du dialogue SIP proprement.
edit: bon finalement rooot a répondu entre temps et le périmètre a changé, je remets mon cerveau dessus ce soir
-
sur d'autres postes dans le forum, certains ne semblent pas avoir ce souci lorsqu'ils utilisent des téléphones ou adaptateurs SIP, dans lesquels il y a d'ailleurs un peu plus de parametres a renseigner.
ici on voit pas mal d'indications et explications : https://lafibre.info/cisco/utilisation-dun-cisco-spa112-pour-la-telephone-voip-de-votre-abonnement-sfr/
-
@ Rooot : le compte de ton MicroSIP me parait bizarre :
--> SIP Server : il n'y a pas de username "+33xxxxxxxxx". Je dois en mettre un chez moi, sinon, ça ne fonctionne pas.
--> SIP Proxy : residential n'existe pas. Il faut mettre "mitry", "corbas" ou "trappes".
--> Public Address : que je mette mon adresse IP WAN ou pas, c'est pareil.
Le paramétrage :
--> j'ai les mêmes codecs.
--> source port : je n'ai rien mis.
--> RTP Ports : je n'ai rien mis.
--> nameserver : je n'ai rien mis.
--> STUN Server : j'ai coché, sinon ça ne fonctionne pas chez moi.
Ne vous perdez pas les réglages et essayez de suivre la logique et le chemin des paquets.
J'ai testé plusieurs combinaisons dans le paramétrage, sans avoir résolu le problème. La solution se trouve ailleurs que dans le SoftPhone.
@ Rooot : l'adresse IP 92.91.128.24 est celle du serveur proxy de mitry.
Concernant la fin de la requête SIP, celle où il manque ceci (en rouge) : "Request: INVITE sip:+33xxxxxxxxx@ims.mnc010.mcc208.gppnetwork.org:5062;transport=udp;ob". Ne serait ce pas ça le problème ?
Je ne dis pas le contraire, mais là les paquets arrivent sur son WAN, mais visiblement son soft ne reçoit rien. Il faut déjà régler ça amha
Je me suis mis en DMZ dans la Box SFR et ouvert le pare-feu Windows afin de ne rien avoir de bloquant. Le SIP ALG est coupé aussi. Pareil, le problème persiste.
Sous Debian, derrière l'ONT, sans pare-feu (iptables), j'ai aussi le même problème.
sur d'autres postes dans le forum, certains ne semblent pas avoir ce souci lorsqu'ils utilisent des téléphones ou adaptateurs SIP, dans lesquels il y a d'ailleurs un peu plus de paramètres a renseigner.
Justement, avec un téléphone VOIP/SIP comme les Gigaset IP, est ce que le problème ne se serait pas résolu de lui même ?
Ce qui voudrait dire qu'il manque quelque chose dans la configuration des routeurs et des ordinateurs.
Un problème de NAT peut-être, sans savoir lequel.
-
@ Rooot : le compte de ton MicroSIP me parait bizarre :
--> SIP Server : il n'y a pas de username "+33xxxxxxxxx". Je dois en mettre un chez moi, sinon, ça ne fonctionne pas.
--> SIP Proxy : residential n'existe pas. Il faut mettre "mitry", "corbas" ou "trappes".
--> Public Address : que je mette mon adresse IP WAN ou pas, c'est pareil.
Le paramétrage :
--> j'ai les mêmes codecs.
--> source port : je n'ai rien mis.
--> RTP Ports : je n'ai rien mis.
--> nameserver : je n'ai rien mis.
--> STUN Server : j'ai coché, sinon ça ne fonctionne pas chez moi.
J'ai testé plusieurs combinaisons dans le paramétrage, sans avoir résolu le problème. La solution se trouve ailleurs que dans le SoftPhone.
Si tu configures exactement comme je l'ai fait ca doit marcher...On m'a dit que c'etait plus juste de faire comme cela. Mais au final ca ne marche pas mieux donc bon...
Tu as bien mis les DNS de SFR comme je l'ai fait ?
Hormis la coupure au bout de 30s chez moi ces reglages fonctionnent, ca devrait marcher chez tout le monde...Comme tu peux le voir je suis bien enregistré sur les serveur SFR, je suis "Online".
(https://i.imgur.com/UUUdvkH.png)
On retrouve d'ailleurs ces parametres dans la requete envoyée par la BOX SFR lors de son démarage, pour récupérer les parametres VOIP :
(https://i.imgur.com/EYLJmy1.png)
-
Si je remplace "mitry.p-cscf.sfr.net" par "residential.p-cscf.sfr.net" ça me met "erreur de passerelle".
"residential" n'existe pas comme tu peux le constater si après :
C:\>nslookup residential.p-cscf.sfr.net 109.0.66.10
Serveur : vip-dns-gp-primary.dns.sfr.net
Address: 109.0.66.10
*** vip-dns-gp-primary.dns.sfr.net ne parvient pas à trouver residential.p-cscf.sfr.net : Non-existent domain
C:\>alors que "mitry", "corbas" ou "trappes" existent :
C:\>nslookup mitry.p-cscf.sfr.net 109.0.66.10
Serveur : vip-dns-gp-primary.dns.sfr.net
Address: 109.0.66.10
Réponse ne faisant pas autorité :
Nom : mitry.p-cscf.sfr.net
Addresses: 2a02:8400:20:22a::8
2a02:8400:20:22b::8
2a02:8400:20:22c::8
2a02:8400:20:229::8
2a02:8400:20:228::8
92.91.129.24
92.91.129.40
92.91.129.56
92.91.129.72
92.91.129.8
C:\>nslookup corbas.p-cscf.sfr.net 109.0.66.20
Serveur : vip-dns-gp-secondary.dns.sfr.net
Address: 109.0.66.20
Réponse ne faisant pas autorité :
Nom : corbas.p-cscf.sfr.net
Addresses: 2a02:8400:20:120b::8
2a02:8400:20:1208::8
2a02:8400:20:120a::8
2a02:8400:20:1209::8
2a02:8400:20:120c::8
92.91.179.56
92.91.179.40
92.91.179.8
92.91.179.72
92.91.179.24
C:\>nslookup trappes.p-cscf.sfr.net 109.0.66.20
Serveur : vip-dns-gp-secondary.dns.sfr.net
Address: 109.0.66.20
Réponse ne faisant pas autorité :
Nom : trappes.p-cscf.sfr.net
Addresses: 2a02:8400:20:239::8
2a02:8400:20:238::8
2a02:8400:20:23a::8
2a02:8400:20:23b::8
2a02:8400:20:23c::8
92.91.129.136
92.91.129.168
92.91.129.184
92.91.129.200
92.91.129.152
C:\>Tu as bien mis les DNS de SFR comme je l'ai fait ?
Avec ou sans les DNS, j'ai quand même la communication.
J'ai bien renseigné mon adresse IP WAN dans le compte. C'est d'ailleurs pour ça que je n'ai pas besoin du serveur STUN.
Et si le protocole téléphonique utilisé par SFR n'était pas du SIP comme on le pense, ça serait quoi ?
-
Bien vu ! je viens de faire une capture depuis le routeur, et pas de status 180 Ringing et encore moins de 200 OK
(https://i.imgur.com/G1eDuim.png)
Et en parallele sur les requettes DNS capturées, puisque c'es de l'UDP, je vois ceci qui m'interpelle :
(https://i.imgur.com/1cXWbi0.png)
Re !
Bon je regarde ça avec un oeil neuf et cette réponse m'interpelle.
Ton client SIP doit résoudre un NDD (visiblement après la réponse "183 Session progress", j'imagine que le serveur en face te demande de chercher l'appel là bas), mais tu n'arrives pas à le résoudre.
-
Si je remplace "mitry.p-cscf.sfr.net" par "residential.p-cscf.sfr.net" ça me met "erreur de passerelle".
"residential" n'existe pas comme tu peux le constater si après :
et pourquoi cela fonctionne chez moi ? tu peux aussi le constater sur mes images écran.
EDIT:
j'arrive a reproduire ton "erreur de passerelle" si je ne mets pas les DNS de sfr dans Microsip. Dès que je les mets et que je sauvegarde je repasse "Online" immediatement.
Pourtant sur mon PC et sur le routeur j'ai remplacé mes DNS 1.1.1.1 et 8.8.8.8 par ceux de SFR...
-
Re !
Bon je regarde ça avec un oeil neuf et cette réponse m'interpelle.
Ton client SIP doit résoudre un NDD (visiblement après la réponse "183 Session progress", j'imagine que le serveur en face te demande de chercher l'appel là bas), mais tu n'arrives pas à le résoudre.
C'est le champ A qu'il n'arrive pas a résoudre, mais est-ce que c'est celui là dont on a besoin ? parce que si je ne dis pas de betise et si ma mémoire ne me joue pas des tours, que j'utilise,
"residential.p-cscf.sfr.net" ou "corbas.p-cscf.sfr.net" le résultat est le même...
je vais refaire un test pour vérifier.
EDIT:
Voilà, je suis FULL DNS SFR: PC/ROUTEUR/Microsip
avec SIP Proxy sur : corbas.p-cscf.sfr.net:5062
Voici le résultat :
(https://i.imgur.com/YLiHdCM.png)
-
@artemus24
nslookup -q=srv _sip._udp.residential.p-cscf.sfr.net 109.0.66.10
(https://i.imgur.com/Gz5A2n5.png)
Source : https://docs.opnsense.org/manual/how-tos/sfr_red_fr_ftth.html
Donc en passant par residential.p-cscf.sfr.net en fait on passe par un "load balancing" qui va attribuer un des 3 serveurs.
-
Merci Rooot. :)
Voilà comment j'écris le serveur Proxy dans MicroSIP : "mitry.p-cscf.sfr.net:5062". Si je ne mets pas le port5062, ça ne fonctionne pas.
Je comprends mieux pourquoi il faut utiliser ton residential. Voici ce que j'obtiens :
C:\>nslookup -type=all _sip._udp.residential.p-cscf.sfr.net 109.0.66.10
Serveur : vip-dns-gp-primary.dns.sfr.net
Address: 109.0.66.10
Réponse ne faisant pas autorité :
_sip._udp.residential.p-cscf.sfr.net SRV service location:
priority = 10
weight = 0
port = 5062
svr hostname = mitry.p-cscf.sfr.net
_sip._udp.residential.p-cscf.sfr.net SRV service location:
priority = 10
weight = 0
port = 5062
svr hostname = corbas.p-cscf.sfr.net
_sip._udp.residential.p-cscf.sfr.net SRV service location:
priority = 10
weight = 0
port = 5062
svr hostname = trappes.p-cscf.sfr.net
C:\>Sauf que le mettre dans MicroSIP provoque une "erreur de passerelle". Ou alors, il y a d'autres déclarations à faire dans mon ordinateur pour que ce "residential" soit opérationnel.
Est-ce que tu utilises Siproxd ?
-
Voilà comment j'écris le serveur Proxy dans MicroSIP : "mitry.p-cscf.sfr.net:5062". Si je ne mets pas le port5062, ça ne fonctionne pas.
si tu utilies mitry, trappes, ou corbas alors il faut indiquer le port. Pas si tu utilises "residential", car l'application decouvre le domaine et le port avec la requete nslookup que j'ai indiqué plus haut.
Mais au final tout ca n'apporte pas grand chose vu que ca ne regle pas le problème qu'on a ;D
concernant le champ champ SIP Server, il faut bien mettre : "ims.mnc010.mcc208.3gppnetwork.org" et non "+33xxxxxxxxxx@ims.mnc010.mcc208.3gppnetwork.org"
L'appli prend le texte que tu as mis dans "Account name" et le combien avec le "sip server" pour donner justement le "+33xxxxxxxxxx@ims.mnc010.mcc208.3gppnetwork.org"
Donc "Account name" = +33xxxxxxxxxxx
et "sip server" = ims.mnc010.mcc208.3gppnetwork.org
et ca doit fonctionner.
Pour siproxd, non, j'ai essayé de l'installer mais je n'ai pas compris comment ca se parametre donc j'ai laissé tombé.
-
Ca y est, j'ai enfin compris. Le "residential.p-cscf.sfr.net" s'utilise conjointement avec les DNS SFR 109.0.66.10 et 109.0.66.20.
Je dois être fatigué à force de chercher et de ne pas comprendre ce que je fais.
Dans Le paramétrage de MicroSIP, le séparateur des adresses IP des serveurs DNS est la virgule et non le point virgule.
-
Dans Le paramétrage de MicroSIP, le séparateur des adresses IP des serveurs DNS est la virgule et non le point virgule.
si je supprime le contenu de ce champ, et que je décoche et recoche "DNS SRV" alors ça m'affiche 8.8.8.8; 8.8.4.4
donc je pense que le séparateur est le point virgule... ;D
-
Bonjour,
Je viens de créer un compte sur lafibre.info et me joins tardivement à la conversation parce que quelqu’un m’a contacté sur Matrix à propos de ce sujet précis. :)
L’intervalle de 32 secondes entre le début et la coupure de l’appel correspond au timeout par défaut d’une transaction SIP.
Une première capture d’écran de Wireshark montre un message 183 Session Progress envoyé dans la transaction INVITE par le P-CSCF. C’est une méthode pour mettre en place une session avant le décroché de l’appel (le plus souvent, ça sert à jouer une tonalité de retour d’appel dans la bande). On parle dans ce cas d’« early media ». Puisque ces messages sont réémis avec l’algorithme de backoff classique du SIP (d’abord après 500 ms, puis 1000, 2000, 4000 jusqu’à expiration du timer), on peut supposer que le P-CSCF s’attendait à recevoir un PRACK de la part du client (cf. RFC 3262 pour les détails du PRACK). Sans PRACK dans les temps, le P-CSCF fait échouer l’INVITE avec une réponse 5xx.
Dans une seconde capture, je vois un 183 suivi d’un train de paquets RTP du client jusqu’au P-CSCF. C’est bon signe : cela signifie que la réponse SDP contenu dans le 183 est parvenu jusqu’au client. Mais il n’y a pas de trafic RTP dans l’autre sens, ni de PRACK du client.
Dans le doute, ce serait très utile de faire une capture tcpdump sur le routeur, avec l’option -i any et en enregistrant la capture dans un fichier, pour voir ce qui se passe exactement avec les trafics SIP et RTP au franchissement du NAT.
-
Bonjour X0r, bienvenue dans ce forum.
Ton pseudo m'est familier car on parle de toi dans ce forum, en admettant qu'il s'agisse bien du même X0r. :)
Pour WireShark, je laisse Rooot se charger de cela, s'il le veut bien, car il est plus coutumier de ce genre de manipulation.
L’intervalle de 32 secondes entre le début et la coupure de l’appel correspond au timeout par défaut d’une transaction SIP.
Sous Asterisk, on retrouve cette valeur en faisant :
Debian*CLI> pjsip show auth sfr
I/OAuth: <AuthId/UserName.............................................................>
==========================================================================================
Auth: sfr/NDIXXXXXXXXXX.XXX.XXX@sfr.fr
ParameterName : ParameterValue
=============================================
auth_type : userpass
md5_cred :
nonce_lifetime : 32
oauth_clientid :
oauth_secret :
password : MMMMMMMMMMMMMMMM
realm :
refresh_token :
username : NDIXXXXXXXXXX.XXX.XXX@sfr.fr
Debian*CLI> on peut supposer que le P-CSCF s’attendait à recevoir un PRACK de la part du client (cf. RFC 3262 pour les détails du PRACK).
Comment cela se résout sous Asterisk ?
-
Bonjour,
Ton pseudo m'est familier car on parle de toi dans ce forum, en admettant qu'il s'agisse bien du même X0r. :)
Oui, il s’agit bien du même x0r et je peux le prouver. :)
Sous Asterisk, on retrouve cette valeur en faisant :
Debian*CLI> pjsip show auth sfr
I/OAuth: <AuthId/UserName.............................................................>
==========================================================================================
Auth: sfr/NDIXXXXXXXXXX.XXX.XXX@sfr.fr
ParameterName : ParameterValue
=============================================
auth_type : userpass
md5_cred :
nonce_lifetime : 32
oauth_clientid :
oauth_secret :
password : MMMMMMMMMMMMMMMM
realm :
refresh_token :
username : NDIXXXXXXXXXX.XXX.XXX@sfr.fr
Debian*CLI>
Houlà non, ça n’a rien à voir ; ça concerne l’authentification (et je pense que ce paramètre n’a aucune importance dans notre cas de figure).
La bonne valeur se lit avec pjsip show settings : à la toute fin il y a timer_b et timer_t1. Le timer T1 est l’intervalle de départ entre l’envoi de la requête et la première retransmission en cas de non-réponse et le timer B est le délai d’attente maximal. T1 vaut 500 ms par défaut et B vaut 64 × T1, soit 32 s. Ces deux timers n’ont d’effet que sur les requêtes SIP partant d’Asterisk ; ici, on voit plutôt les timers positionnés de l’autre côté qui font leur boulot. En tout cas, côté Asterisk, il n’y a vraiment aucune raison de toucher aux timers.
Bref, on s’éloigne du sujet : je voulais juste expliquer d’où venait ce délai de tout pile 32 secondes, et pourquoi pas 30 ou autre.
Comment cela se résout sous Asterisk ?
Là comme ça je n’ai pas encore assez d’informations. Je soupçonne de deux choses l’une : (a) quelque chose sur le trajet de l’infra de SFR jusqu’à Asterisk fait que ces messages 183 Session Progress ne parviennent jamais à Asterisk, ou (b) ce sont les réponses PRACK d’Asterisk, qui servent à accuser réception d’un 183 Session Progress, qui ne parviennent jamais à SFR.
D’où le besoin d’une capture de paquets sur le routeur pour savoir ce qui se passe.
-
Houlà non, ça n’a rien à voir ; ça concerne l’authentification (et je pense que ce paramètre n’a aucune importance dans notre cas de figure).
Désolé de ma méprise. :-[
La bonne valeur se lit avec pjsip show settings : à la toute fin il y a timer_b et timer_t1.
Voici ce que j'ai dans mon Asterisk :
Debian*CLI> pjsip show settings
Global Settings:
ParameterName : ParameterValue
======================================================================
all_codecs_on_empty_reinvite : false
allow_sending_180_after_183 : false
contact_expiration_check_interval : 30
debug : no
default_from_user : asterisk
default_outbound_endpoint : default_outbound_endpoint
default_realm : asterisk
default_voicemail_extension :
disable_multi_domain : false
endpoint_identifier_order : ip,username,anonymous
ignore_uri_user_options : false
keep_alive_interval : 90
max_forwards : 70
max_initial_qualify_time : 0
mwi_disable_initial_unsolicited : false
mwi_tps_queue_high : 500
mwi_tps_queue_low : -1
norefersub : yes
regcontext :
send_contact_status_on_update_registration : no
taskprocessor_overload_trigger : global
unidentified_request_count : 5
unidentified_request_period : 5
unidentified_request_prune_interval : 30
use_callerid_contact : no
user_agent : Asterisk PBX 20.4.0
System Settings:
ParameterName : ParameterValue
============================================
accept_multiple_sdp_answers : false
compact_headers : false
disable_rport : false
disable_tcp_switch : true
follow_early_media_fork : true
threadpool_auto_increment : 5
threadpool_idle_timeout : 60
threadpool_initial_size : 0
threadpool_max_size : 50
timer_b : 32000
timer_t1 : 500
Debian*CLI> Le time_b est à 32000. Je suppose que ce sont des millisecondes.
Dans ce sujet, Rooot a fait des captures avec WireShark.
-
@ X0r : sous Asterisk, j'ai fait une trace de l'appel au 1023 (Service client SFR) que tu peux consulter dans mon autre sujet (https://lafibre.info/remplacer-sfr/utilisation-dasterisk-sous-debian-11/).
Je ne sais pas si cela va t'être utile pour comprendre le problème des 32 secondes.
-
Salut,
Je ne sais pas si ça pourrait résoudre ton soucis, mais pourquoi ne pas d'abord essayer une config plus simple dont on est sûr que ça fonctionne ? Avec IPPI ou OVH par ex ? Ça permettrait de valider que les appels sortants fonctionnent à coup sûr. Et si c'est le cas, c'est que le soucis est spécifique à SFR vu que le paramétrage est assez spécial.
Sur ton autre post je vois qu'il n'y a pas de paramètre relatif au qualify (pour garder le NAT ouvert notamment) Ton soucis ne viendrait pas en partie de là par hasard ? Car ça me rappelle un problème similaire que j'ai eu avec OVH et rajouter le qualify avait résolu le soucis je crois bien.
Quand tu affiche les peers, SFR a quel statut ? Si c'est unreachable ou unknown, c'est pas bon...
-
Excellent, merci pour les traces. Je viens de regarder les traces générées par PJSIP.
Le 183 Session Progress transmis par SFR ressemble à ceci :
SIP/2.0 183 Session Progress
Call-ID: 81d21fe3-eec7-4eaf-870c-ed8709c94c69
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5060;received=XXX.XXX.XXX.XXX;branch=z9hG4bKPj857447e6-2a77-4c42-9111-4983a01df4ce;rport=5060
To: <sip:1023@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=64a4ab95-64dcdc3711acc271-gm-po-lucentPCSF-057234
From: <sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org;user=phone>;tag=d27f1e12-b985-4872-9327-ab9493c4a35d
CSeq: 23228 INVITE
Require: 100rel
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,PRACK,INFO,REFER,UPDATE
Contact: <sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062;x-afi=105>
Content-Type: application/sdp
RSeq: 1
Content-Length: 235
v=0
o=LucentPCSF 1631970971 1631970971 IN IP4 imsgroup-019.tng1asbc05.ims.sfr.net
s=-
c=IN IP4 92.91.230.139
t=0 0
m=audio 35412 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=ptime:20
a=silenceSupp:off - - - -
Cette réponse contient un en-tête Contact, que j’ai mis en gras car il est en fait très important. Il contient l’URI SIP où Asterisk doit envoyer tous les messages SIP, dorénavant, dans le contexte de l’appel téléphonique (plus précisément, le dialogue INVITE). La présence simultanée des en-têtes Require: 100rel et RSeq signifie, d’après la RFC 3262 (https://datatracker.ietf.org/doc/html/rfc3262 (https://datatracker.ietf.org/doc/html/rfc3262)), qu’Asterisk doit envoyer un message PRACK, pour accuser réception du 183 Session Progress, à l’URI SIP indiquée dans le Contact. Or je ne vois pas de PRACK partir du côté d’Asterisk : je pense qu’il n’a pas réussi à résoudre le nom de domaine pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net. Sans ça, rien ne part. À tous les coups, ce nom de domaine ne peut être résolu qu’en passant par un résolveur bien particulier.
Sur la machine exécutant Asterisk, lance la commande dig pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net (et si dig n’est pas installé, ça se trouve dans un paquet « bind-utils » ou « bind-tools », en général). Obtiens-tu une réponse DNS NOERROR ou NXDOMAIN ?
Et avec dig @109.0.66.10 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net ?
-
Apparemment y'a un soucis avec ces domaines... Message de rooot page 3 (https://lafibre.info/remplacer-sfr/red-by-sfr-appels-sip-sortant-coupes-au-bout-de-32-secondes/msg1028762/#msg1028762)
On voit sur sa capture que le DNS de SFR répond un NXDOMAIN pour pcgw-0006.imsgroup-015.mit2asbc03.ims.sfr.fr au nom assez proche.
-
Merci. On tient la « root cause » du problème, je pense.
Reste plus qu’à savoir quels sont les serveurs DNS faisant réellement autorité pour ims.sfr.net. Depuis ma ligne Orange, c’est nspri00.dns.sfr.net (109.0.66.6) et nspri01.dns.sfr.net (109.0.66.16), mais ça doit être différent pour les abonnés SFR. Par curiosité, quelqu’un peut-il faire un dig SOA ims.sfr.net puis un dig NS ims.sfr.net depuis une ligne SFR ?
-
@ Renaud07 : j'ai la communication qui se fait puisque j'entends le répondeur du service client SFR. Il me semble que ce n'est pas un problème de configuration puisque j'ai repris cette configuration dans ce forum.
Et si c'est le cas, c'est que le soucis est spécifique à SFR vu que le paramétrage est assez spécial.
C'est ce que je crois, le soucis vient de la complexité de SFR, mais aussi qu'il doit manquer quelque chose coté Zoiper5 ou coté Asterisk.
Sur ton autre post je vois qu'il n'y a pas de paramètre relatif au qualify (pour garder le NAT ouvert notamment) Ton soucis ne viendrait pas en partie de là par hasard ? Car ça me rappelle un problème similaire que j'ai eu avec OVH et rajouter le qualify avait résolu le soucis je crois bien.
Je ne sais pas de quoi tu me parles. Peux-tu m'indiquer ce qui manque dans ma configuration, stp ?
Je te donne la liste des commandes de la console Asterisk :
Debian*CLI> core show help
! -- Execute a shell command
acl show -- Show a named ACL or list all named ACLs
aoc set debug -- enable cli debugging of AOC messages
bridge kick -- Kick a channel from a bridge
bridge show all -- List all bridges
bridge show -- Show information about a bridge
bridge technology show -- List registered bridge technologies
bridge technology {suspend|unsuspend} -- Suspend/unsuspend a bridge technology
cc cancel [core|all] -- Kill a CC transaction
cc report status -- Reports CC stats
cdr set debug [on|off] -- Enable debugging in the CDR engine
cdr show active -- Display active CDRs for channels
cdr show status -- Display the CDR status
cdr submit -- Posts all pending batched CDR data
cel show status -- Display the CEL status
channel request hangup -- Request a hangup on a given channel
cli check permissions -- Try a permissions config for a user
cli reload permissions -- Reload CLI permissions config
cli show permissions -- Show CLI permissions
confbridge kick -- Kick participants out of conference bridges.
confbridge list -- List conference bridges and participants.
confbridge lock -- Lock a conference.
confbridge mute -- Mute participants.
confbridge record start -- Start recording a conference
confbridge record stop -- Stop recording a conference.
confbridge show menu -- Show a conference menu
confbridge show menus -- Show a list of conference menus
confbridge show profile bridge -- Show a conference bridge profile.
confbridge show profile bridges -- Show a list of conference bridge profiles.
confbridge show profile user -- Show a conference user profile.
confbridge show profile users -- Show a list of conference user profiles.
confbridge unlock -- Unlock a conference.
confbridge unmute -- Unmute participants.
config list -- Show all files that have loaded a configuration file
config reload -- Force a reload on modules using a particular configuration file
config show help -- Show configuration help for a module
core abort shutdown -- Cancel a running shutdown
core clear profile -- Clear profiling info
core ping taskprocessor -- Ping a named task processor
core reload -- Global reload
core reset taskprocessor -- Reset a named task processor's stats
core reset taskprocessors -- Reset all task processors' stats
core restart gracefully -- Restart Asterisk gracefully
core restart now -- Restart Asterisk immediately
core restart when convenient -- Restart Asterisk at empty call volume
core set debug category -- Enable/disable debugging categories
core set debug -- Set level of debug chattiness
core set debug channel -- Enable/disable debugging on a channel
core set trace -- Set level of trace chattiness
core set verbose -- Set level of verbose chattiness
core show applications [like|describing] -- Shows registered dialplan applications
core show application -- Describe a specific dialplan application
core show calls [uptime] -- Display information on calls
core show channels [concise|verbose|count] -- Display information on channels
core show channeltypes -- List available channel types
core show channeltype -- Give more details on that channel type
core show channel -- Display information on a specific channel
core show codecs [audio|video|image|text] -- Displays a list of registered codecs
core show codec -- Shows a specific codec
core show config mappings -- Display config mappings (file names to config engines)
core show file formats -- Displays file formats
core show functions [like] -- Shows registered dialplan functions
core show function -- Describe a specific dialplan function
core show hanguphandlers all -- Show hangup handlers of all channels
core show hanguphandlers -- Show hangup handlers of a specified channel
core show help -- Display help list, or specific help on a command
core show hints -- Show dialplan hints
core show hint -- Show dialplan hint
core show image formats -- Displays image formats
core show license -- Show the license(s) for this copy of Asterisk
core show profile -- Display profiling info
core show settings -- Show some core settings
core show sounds -- Shows available sounds
core show sound -- Shows details about a specific sound
core show switches -- Show alternative switches
core show sysinfo -- Show System Information
core show taskprocessor alerted subsystems -- List task processor subsystems in alert
core show taskprocessors [like] -- List instantiated task processors and statistics
core show threads -- Show running threads
core show translation -- Display translation matrix
core show uptime [seconds] -- Show uptime information
core show version -- Display version info
core show warranty -- Show the warranty (if any) for this copy of Asterisk
core stop gracefully -- Gracefully shut down Asterisk
core stop now -- Shut down Asterisk immediately
core stop when convenient -- Shut down Asterisk at empty call volume
core waitfullybooted -- Wait for Asterisk to be fully booted
database del -- Removes database key/value
database deltree -- Removes database keytree/values
database get -- Gets database value
database put -- Adds/updates database value
database query -- Run a user-specified query on the astdb
database show -- Shows database contents
database showkey -- Shows database contents
devstate change -- Change a custom device state
devstate list -- List currently known custom device states
dialplan add extension -- Add new extension into context
dialplan add ignorepat -- Add new ignore pattern
dialplan add include -- Include context in other context
dialplan debug -- Show fast extension pattern matching data structures
dialplan eval function -- Evaluate dialplan function
dialplan reload -- Reload extensions and *only* extensions
dialplan remove context -- Remove a specified context
dialplan remove extension -- Remove a specified extension
dialplan remove ignorepat -- Remove ignore pattern from context
dialplan remove include -- Remove a specified include from context
dialplan save -- Save current dialplan into a file
dialplan set chanvar -- Set a channel variable
dialplan set extenpatternmatchnew false -- Use the Old extension pattern matching algorithm.
dialplan set extenpatternmatchnew true -- Use the New extension pattern matching algorithm.
dialplan set global -- Set global dialplan variable
dialplan show -- Show dialplan
dialplan show chanvar -- Show channel variables
dialplan show globals -- Show global dialplan variables
dnsmgr refresh -- Performs an immediate refresh
dnsmgr reload -- Reloads the DNS manager configuration
dnsmgr status -- Display the DNS manager status
features show -- Lists configured features
group show channels -- Display active channels with group(s)
http show status -- Display HTTP server status
indication add -- Add the given indication to the country
indication remove -- Remove the given indication from the country
indication show -- Display a list of all countries/indications
local show channels -- List status of local channels
logger add channel -- Adds a new logging channel
logger mute -- Toggle logging output to a console
logger reload -- Reopens the log files
logger remove channel -- Removes a logging channel
logger rotate -- Rotates and reopens the log files
logger set level {DEBUG|TRACE|NOTICE|WARNING|ERROR|VERBOSE|DTMF} {on|off} -- Enables/Disables a specific logging level for this console
logger show channels -- List configured log channels
logger show levels -- List configured log levels
malloc trim -- Return excess memory to the OS
manager reload -- Reload manager configurations
manager set debug [on|off] -- Show, enable, disable debugging of the manager code
manager show command -- Show a manager interface command
manager show commands -- List manager interface commands
manager show connected -- List connected manager interface users
manager show eventq -- List manager interface queued events
manager show events -- List manager interface events
manager show event -- Show a manager interface event
manager show settings -- Show manager global settings
manager show users -- List configured manager users
manager show user -- Display information on a specific manager user
media cache create -- Create an item in the media cache
media cache delete -- Remove an item from the media cache
media cache refresh -- Refresh an item in the media cache
media cache show all -- Show all items in the media cache
media cache show -- Show a single item in the media cache
module load -- Load a module by name
module refresh -- Completely unloads and loads a module by name
module reload -- Reload configuration for a module
module show [like] -- List modules and info
module unload -- Unload a module by name
moh reload -- Reload MusicOnHold
moh show classes -- List MusicOnHold classes
moh show files -- List MusicOnHold file-based classes
moh unregister class -- Unregister realtime MusicOnHold class
no debug channel -- Disable debugging on channel(s)
pjproject set log level {default|0|1|2|3|4|5|6} -- Set the maximum active pjproject logging level
pjproject show buildopts -- Show the compiled config of the pjproject in use
pjproject show log level -- Show the maximum active pjproject logging level
pjproject show log mappings -- Show pjproject to Asterisk log mappings
pjsip dump endpt -- Dump the res_pjsip endpt internals
pjsip list aors -- List PJSIP Aors
pjsip list auths -- List PJSIP Auths
pjsip list channels -- List PJSIP Channels
pjsip list ciphers -- List available OpenSSL cipher names
pjsip list contacts -- List PJSIP Contacts
pjsip list endpoints -- List PJSIP Endpoints
pjsip list identifies -- List PJSIP Identifies
pjsip list registrations -- List PJSIP Registrations
pjsip list subscriptions {inbound|outbound} [like] -- List active inbound/outbound subscriptions
pjsip list transports -- List PJSIP Transports
pjsip qualify -- Send an OPTIONS request to a PJSIP endpoint
pjsip reload qualify aor -- Synchronize the PJSIP Aor qualify options
pjsip reload qualify endpoint -- Synchronize the qualify options for all Aors on the PJSIP endpoint
pjsip send notify -- Send a NOTIFY request to a SIP endpoint
pjsip send register -- Registers an outbound registration target
pjsip send unregister -- Unregisters outbound registration target
pjsip set logger {on|off|host|add|method|methodadd|verbose|pcap} -- Enable/Disable PJSIP Logger Output
pjsip show aors -- Show PJSIP Aors
pjsip show aor -- Show PJSIP Aor
pjsip show auths -- Show PJSIP Auths
pjsip show auth -- Show PJSIP Auth
pjsip show channels -- Show PJSIP Channels
pjsip show channel -- Show PJSIP Channel
pjsip show channelstats -- Show PJSIP Channel Stats
pjsip show contacts -- Show PJSIP Contacts
pjsip show contact -- Show PJSIP Contact
pjsip show endpoints -- Show PJSIP Endpoints
pjsip show endpoint -- Show PJSIP Endpoint
pjsip show identifiers -- List registered endpoint identifiers
pjsip show identifies -- Show PJSIP Identifies
pjsip show identify -- Show PJSIP Identify
pjsip show qualify aor -- Show the PJSIP Aor current qualify options
pjsip show qualify endpoint -- Show the current qualify options for all Aors on the PJSIP endpoint
pjsip show registrations -- Show PJSIP Registrations
pjsip show registration -- Show PJSIP Registration
pjsip show scheduled_tasks -- Show pjsip scheduled tasks
pjsip show settings -- Show global and system configuration options
pjsip show subscription {inbound|outbound} -- Show active subscription details
pjsip show subscriptions {inbound|outbound} [like] -- Show active inbound/outbound subscriptions
pjsip show transport-monitors -- Show pjsip transport monitors
pjsip show transports -- Show PJSIP Transports
pjsip show transport -- Show PJSIP Transport
pjsip show unidentified_requests -- Show PJSIP Unidentified Requests
pjsip show version -- Show the version of pjproject in use
queue add member -- Add a channel to a specified queue
queue priority caller -- Change priority caller on queue
queue reload {parameters|members|rules|all} -- Reload queues, members, queue rules, or parameters
queue remove member -- Removes a channel from a specified queue
queue reset stats -- Reset statistics for a queue
queue set penalty -- Set penalty for a channel of a specified queue
queue set ringinuse -- Set ringinuse for a channel of a specified queue
queue show -- Show status of a specified queue
queue show rules -- Show the rules defined in queuerules.conf
queue {pause|unpause} member -- Pause or unpause a queue member
rtcp set debug {on|off|ip} -- Enable/Disable RTCP debugging
rtcp set stats {on|off} -- Enable/Disable RTCP stats
rtp set debug {on|off|ip} -- Enable/Disable RTP debugging
rtp show settings -- Display RTP settings
say load [new|old] -- Set or show the say mode
stasis show topics -- Show all topics
stasis show topic -- Show topic
stun set debug {on|off} -- Enable/Disable STUN debugging
timing test -- Run a timing test
udptl set debug {on|off|ip} -- Enable/Disable UDPTL debugging
udptl show config -- Show UDPTL config options
voicemail reload -- Reload voicemail configuration
voicemail show aliases -- List mailbox aliases
voicemail show users [for] -- List defined voicemail boxes
voicemail show zones -- List zone message formats
xmldoc dump -- Dump the XML docs to the specified file
xmldoc reload -- Reload the XML docs
Debian*CLI>Quand tu affiche les peers, SFR a quel statut ? Si c'est unreachable ou unknown, c'est pas bon...
Je ne suis pas dans la version 15 ou 16, mais 20 et les commandes ne sont pas les mêmes. Je suis bien enregistré :
Debian*CLI> pjsip show registrations
<Registration/ServerURI..............................> <Auth....................> <Status.......>
==========================================================================================
sfr/sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gppnetwork.org sfr Registered (exp. 3327s)
Objects found: 1
Debian*CLI> Mais comme je l'ai indiqué dans mon autre sujet, j'ai un problème avec cette anomalie :
[Aug 16 19:36:27] WARNING[6749]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000002", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000002'Que signifie ce message d'anomalie ?
@ X0r : voici ce que tu m'as demandé :
> dig pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; <<>> DiG 9.16.42-Debian <<>> pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49821
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net. IN A
;; AUTHORITY SECTION:
ims.sfr.net. 1560 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2020011301 10800 3600 1814400 86400
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 16 19:38:34 CEST 2023
;; MSG SIZE rcvd: 150
~> dig @109.0.66.10 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; <<>> DiG 9.16.42-Debian <<>> @109.0.66.10 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42562
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net. IN A
;; AUTHORITY SECTION:
ims.sfr.net. 1309 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2020011301 10800 3600 1814400 86400
;; Query time: 24 msec
;; SERVER: 109.0.66.10#53(109.0.66.10)
;; WHEN: Wed Aug 16 19:42:44 CEST 2023
;; MSG SIZE rcvd: 150
~>
-
> dig SOA ims.sfr.net
; <<>> DiG 9.16.42-Debian <<>> SOA ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24352
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;ims.sfr.net. IN SOA
;; ANSWER SECTION:
ims.sfr.net. 86127 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2020011301 10800 3600 1814400 86400
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 16 19:45:28 CEST 2023
;; MSG SIZE rcvd: 105
~> dig NS ims.sfr.net
; <<>> DiG 9.16.42-Debian <<>> NS ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53671
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;ims.sfr.net. IN NS
;; ANSWER SECTION:
ims.sfr.net. 86104 IN NS nspri01.dns.sfr.net.
ims.sfr.net. 86104 IN NS nspri00.dns.sfr.net.
;; ADDITIONAL SECTION:
nspri00.dns.sfr.net. 81921 IN A 109.0.66.6
nspri01.dns.sfr.net. 74008 IN A 109.0.66.16
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 16 19:45:50 CEST 2023
;; MSG SIZE rcvd: 127
~> dig @109.0.66.10 pcgw
-
~> dig NS ims.sfr.net
; <<>> DiG 9.16.42-Debian <<>> NS ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57650
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;ims.sfr.net. IN NS
;; ANSWER SECTION:
ims.sfr.net. 76467 IN NS nspri00.dns.sfr.net.
ims.sfr.net. 76467 IN NS nspri01.dns.sfr.net.
;; ADDITIONAL SECTION:
nspri00.dns.sfr.net. 85023 IN A 109.0.66.6
nspri01.dns.sfr.net. 64371 IN A 109.0.66.16
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 16 22:26:28 CEST 2023
;; MSG SIZE rcvd: 127
~> Comment se fait-il qu'un téléphone VOIP/SIP n'a pas ce genre de problème?
-
Comment se fait-il qu'un téléphone VOIP/SIP n'a pas ce genre de problème?
Ils utilisent peut-être des serveurs DNS différents de 109.0.66.10 et .20 pour résoudre les noms en ims.sfr.net ?
-
Les serveurs DNS de SFR sont :
~> nslookup vip-dns-gp-primary.dns.sfr.net
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: vip-dns-gp-primary.dns.sfr.net
Address: 109.0.66.10
Name: vip-dns-gp-primary.dns.sfr.net
Address: 2a02:8400::
~> nslookup vip-dns-gp-secondary.dns.sfr.net
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: vip-dns-gp-secondary.dns.sfr.net
Address: 109.0.66.20
Name: vip-dns-gp-secondary.dns.sfr.net
Address: 2a02:8400::1
~>
-
Ah, j’ai une piste. Sur ce sujet-là : https://lafibre.info/remplacer-sfr/ftth-tuto-bypass-complet-neufbox-avec-un-routeur-openwrt/
Le proxy sortant (outbound proxy) est-il bien configuré ? Il semblerait que ce soit sip:corbas.p-cscf.sfr.net:5062. Ça devrait être configuré avec la variable outbound_proxy dans la section [endpoint] qui correspond à l’infrastructure IMS de SFR.
-
Pour le proxy, je n'utilise pas les adresse suivantes :
--> mitry.p-cscf.sfr.net:5062
--> corbas.p-cscf.sfr.net:5062
--> trappes.p-cscf.sfr.net:5062
mais celle-ci :
--> residential.p-cscf.sfr.net
sans préciser le port 5062 et ça fonctionne.
Normalement, c'est la bonne méthode, et il ne faut surtout pas utiliser l'une des trois ci-dessus.
Il se peut que l'une soit en maintenance, pendant que les deux autres soient opérationnelles.
Si tu es sur Corbas et qu'il est en maintenance, tu n'as plus aucune connexion.
Le proxy sortant (outbound proxy) est-il bien configuré ?
Oui, il est bien configuré car sans cela, je n'aurai pas de connexion.
Dans la section "type=endpoint" du trunk SFR, j'ai :
outbound_proxy=sip:residential.p-cscf.sfr.net\;lrEt en faisant une recherche :
> dig sip:residential.p-cscf.sfr.net
; <<>> DiG 9.16.42-Debian <<>> sip:residential.p-cscf.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45514
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;sip:residential.p-cscf.sfr.net. IN A
;; AUTHORITY SECTION:
p-cscf.sfr.net. 3600 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2023072605 10800 3600 1814400 86400
;; Query time: 40 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 16 23:10:27 CEST 2023
;; MSG SIZE rcvd: 124
~ Du coup, je me demande si je ne dois pas mettre "sip:" devant, ce qui donne :
> dig sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; <<>> DiG 9.16.42-Debian <<>> sip:lucentNGFS-110324@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39626
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;sip:lucentNGFS-110324\@pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net. IN A
;; AUTHORITY SECTION:
ims.sfr.net. 10800 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2020011301 10800 3600 1814400 86400
;; Query time: 36 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 16 23:16:46 CEST 2023
;; MSG SIZE rcvd: 172
~> Ca existe bien.
-
Non justement, le domaine n'existe pas (ça renvoi NXDOMAIN). Il n'y a jamais : dans un nom de domaine, c'est impossible. Le dig demandé par x0r était le bon, mais y'a visiblement un problème de résolution. Soit le DNS n'est pas bon, soit y'a un réel soucis sur celui-ci.
Que donne un dig @109.0.66.6 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net Et le SOA m'intrigue, tu peux faire un dig nspriprov.dns.sfr.net ?
Pour les "peers", je suis en effet toujours avec chan_sip. Je pense que c'est donc pjsip show endpoints
Chez moi, ça ressemble à ça :
SIP*CLI> sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
300/renaud (Unspecified) D No No 0 UNKNOWN
304/renaudpc 192.168.1.11 D Yes Yes 60988 OK (132 ms)
310/GXP L1 192.168.3.10 D Yes Yes 5060 OK (74 ms)
311/GXP L2 192.168.3.10 D Yes Yes 5062 OK (69 ms)
ovh/0033xxxxxxxx 91.121.129.29 Yes Yes 5962 OK (32 ms)
Pour le qualify c'est qualify_frequency=xx à mettre dans la section registration je suppose (je ne connais pas pjsip, faudrait que je m'y mette d'ailleurs) mais à priori ton problème ne vient (pour le moment) à priori pas de là.
Pour le realm, tu devrais regarder ce que fait la box et comparer les captures.
-
Je suis derrière ma Box SFR, et voici le résultat demandé :
~> dig @109.0.66.6 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; <<>> DiG 9.16.42-Debian <<>> @109.0.66.6 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51995
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net. IN A
;; AUTHORITY SECTION:
ims.sfr.net. 86400 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2020011301 10800 3600 1814400 86400
;; Query time: 40 msec
;; SERVER: 109.0.66.6#53(109.0.66.6)
;; WHEN: Thu Aug 17 10:39:27 CEST 2023
;; MSG SIZE rcvd: 132
~> dig nspriprov.dns.sfr.net
; <<>> DiG 9.16.42-Debian <<>> nspriprov.dns.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7266
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nspriprov.dns.sfr.net. IN A
;; AUTHORITY SECTION:
dns.sfr.net. 3600 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2023071201 10800 3600 1814400 86400
;; Query time: 36 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug 17 10:40:34 CEST 2023
;; MSG SIZE rcvd: 94
~> J'ai cherché et je n'ai pas trouvé l'équivalent de la commande "sip show peers". Je ne sais pas si celle-ci va te convenir :
Debian*CLI> pjsip show endpoints
Endpoint: <Endpoint/CID.....................................> <State.....> <Channels.>
I/OAuth: <AuthId/UserName...........................................................>
Aor: <Aor............................................> <MaxContact>
Contact: <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..>
Transport: <TransportId........> <Type> <cos> <tos> <BindAddress..................>
Identify: <Identify/Endpoint.........................................................>
Match: <criteria.........................>
Channel: <ChannelId......................................> <State.....> <Time.....>
Exten: <DialedExten...........> CLCID: <ConnectedLineCID.......>
==========================================================================================
Endpoint: sfr Not in use 0 of inf
OutAuth: sfr/NDIXXXXXXXXXX.AQT.THD@sfr.fr
Aor: sfr 0
Contact: sfr/sip:+33XXXXXXXXX@ims.mnc010.mcc208.3gp e1f7b87c3f NonQual nan
Transport: transport-udp-nat udp 0 0 0.0.0.0:5060
Identify: sfr/sfr
Match: 2a02:8400:20:22c::8/128
Match: 2a02:8400:20:228::8/128
Match: 2a02:8400:20:22b::8/128
Match: 2a02:8400:20:229::8/128
Match: 2a02:8400:20:22a::8/128
Match: 92.91.129.24/32
Match: 92.91.129.8/32
Match: 92.91.129.56/32
Match: 92.91.129.72/32
Match: 92.91.129.40/32
Match: 2a02:8400:20:23a::8/128
Match: 2a02:8400:20:239::8/128
Match: 2a02:8400:20:238::8/128
Match: 2a02:8400:20:23b::8/128
Match: 2a02:8400:20:23c::8/128
Match: 92.91.129.200/32
Match: 92.91.129.152/32
Match: 92.91.129.184/32
Match: 92.91.129.168/32
Match: 92.91.129.136/32
Match: 2a02:8400:20:1209::8/128
Match: 2a02:8400:20:120a::8/128
Match: 2a02:8400:20:120c::8/128
Match: 2a02:8400:20:1208::8/128
Match: 2a02:8400:20:120b::8/128
Match: 92.91.179.72/32
Match: 92.91.179.40/32
Match: 92.91.179.56/32
Match: 92.91.179.8/32
Match: 92.91.179.24/32
Endpoint: zoiper Unavailable 0 of inf
InAuth: zoiper/zoiper
Aor: zoiper 1
Objects found: 2
Debian*CLI> Je me demande si ma Box ne serait pas la cause. Je me mets derrière mon ONT.
Après le "sip:" manquant, je me demande si le port ne serait pas manquant aussi.
~> dig sip:pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062
; <<>> DiG 9.16.42-Debian <<>> sip:pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21950
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;sip:pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062. IN A
;; AUTHORITY SECTION:
. 10730 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023081700 1800 900 604800 86400
;; Query time: 20 msec
;; SERVER: 109.0.66.20#53(109.0.66.20)
;; WHEN: Thu Aug 17 11:59:24 CEST 2023
;; MSG SIZE rcvd: 158
~> Pas de changement, le domaine est "NXDOMAIN", mais avec le dns :
~> dig @nspri01.dns.sfr.net sip:pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062
; <<>> DiG 9.16.42-Debian <<>> @nspri01.dns.sfr.net sip:pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 56313
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sip:pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062. IN A
;; Query time: 40 msec
;; SERVER: 109.0.66.16#53(109.0.66.16)
;; WHEN: Thu Aug 17 12:01:03 CEST 2023
;; MSG SIZE rcvd: 83
~> il est maintenant à refuser.
Je pense que la syntaxe y fait pour beaucoup dans le résultat que l'on recherche.
-
Bon... y'a définitivement un soucis avec le DNS.
Et je le répète, mais rechercher un domaine avec les deux points ne sert à rien, pas plus qu'avec le port, la preuve, le DNS t'envoie bouler. On ne met jamais de port dans un nom de domaine. Pour être précis, tous les caractères spéciaux sont interdits dans un nom de domaine à l'exception du tiret et des lettres accentuées depuis 2012 (https://sketchlex.com/17/02/2012/infographies/caracteres-autorises-pour-la-reservation-fr/) (éèê sont autorisés par ex).
Concernant pjsip show endpoints, ça ne donne pas les infos que je voudrais... faut que je me renseigne un peu mieux. Je me demande pourquoi avec changé de syntaxe, ça à l'air encore plus bordélique d'avant ::)
-
Bonjour me voilà de retour ;D
Pour ce qui est des requetes avec dig j'obtiens, il me semble, comme artemus24.
J'ai effectué les requetes directement depuis mon routeur openwrt, qui a pour DNS ceux de SFR.
dig pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
root@box:~# dig pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; <<>> DiG 9.18.16 <<>> pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15538
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Aug 17 15:11:31 CEST 2023
;; MSG SIZE rcvd: 74
dig @109.0.66.10 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
root@box:~# dig @109.0.66.10 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; <<>> DiG 9.18.16 <<>> @109.0.66.10 pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14376
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net. IN A
;; AUTHORITY SECTION:
ims.sfr.net. 7098 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2020011301 10800 3600 1814400 86400
;; Query time: 20 msec
;; SERVER: 109.0.66.10#53(109.0.66.10) (UDP)
;; WHEN: Thu Aug 17 15:12:51 CEST 2023
;; MSG SIZE rcvd: 150
dig SOA ims.sfr.net
root@box:~# dig SOA ims.sfr.net
; <<>> DiG 9.18.16 <<>> SOA ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35949
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ims.sfr.net. IN SOA
;; ANSWER SECTION:
ims.sfr.net. 85546 IN SOA nspriprov.dns.sfr.net. support.dns.sfr.net. 2020011301 10800 3600 1814400 86400
;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Aug 17 15:13:50 CEST 2023
;; MSG SIZE rcvd: 105
dig NS ims.sfr.net
root@box:~# dig NS ims.sfr.net
; <<>> DiG 9.18.16 <<>> NS ims.sfr.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40012
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ims.sfr.net. IN NS
;; ANSWER SECTION:
ims.sfr.net. 15998 IN NS nspri01.dns.sfr.net.
ims.sfr.net. 15998 IN NS nspri00.dns.sfr.net.
;; ADDITIONAL SECTION:
nspri00.dns.sfr.net. 82557 IN A 109.0.66.6
nspri01.dns.sfr.net. 83457 IN A 109.0.66.16
;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Aug 17 15:14:15 CEST 2023
;; MSG SIZE rcvd: 127
-
Ce "sip:pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net:5062" est une mauvaise piste de recherche.
Je n'ai pas rencontré dans le compte-rendu de la console Asterisk, un message me disant qu'il y avait un problème avec le DNS ou avec l'adresse SIP ci-dessus.
J'ai poursuivi mes lectures dans les forums d'Asterisk et je crois que j'ai trouvé la solution. 8)
Dans Trunk SFR, puis dans la section "type=endpoint", j'ai ajouté l'option suivante :
rewrite_contact=yes"J'ai fait mon test derrière la Box SFR.
Comme à mon accoutumé, j'appel le 1023 et cette fois-ci, j'ai largement dépassé les 32 secondes.
Pas de message "183 Progress" dans la console Asterisk.
Durant la communication, en dehors du "#, je n'ai rien tapé d'autre et c'est le répondeur qui m'a déconnecté.
J'utilise Asterisk 20, version 20.4.0.
La solution se trouve en effet dans le chan_pjsip et non dans le chan_sip.
En ce qui me concerne sur cet aspect des 32 secondes, c'est résolu ! :D
Il me reste deux choses à traiter :
--> Asterisk sous IPv6
--> le dialplan que je détaille ici :
a) j'ai un téléphone Gigaset (je ne l'ai pas encore acheté, mais on fera comme si), un SoftPhone Zoipier, et un autre SoftPhone MicroSIP.
Soit trois téléphones.
b) les communications entrantes se feront toutes vers le Gigaset, à savoir mon téléphone fixe en VOIP/SIP.
c) je dois pouvoir communiquer avec l'extérieur depuis mes trois téléphones.
d) depuis mes SoftPhone, je dois être capable d'intercepter la communication entrante vers le Gigaset.
e) en communication intérieur, être capable d'appeler depuis l'un des trois téléphones.
f) mettre en place un répondeur.
Pour la suite, je ne sais pas trop ce que je dois ajouter.[/code]
-
Bravo !! 8)
Ca mérite une médaille, et un tuto pour l'installation d'astérisk sans passer par des liens de droite et de gauche ;D
Bon perso je reste quand meme sur ma faim. On devrait pouvoir faire fonctioner la Voip sans asterisk, à moins qu'il y ait justement Asterisk dans le routeur SFR...ce qui fait que du coup c'est indispensable, sauf pour les telephones SIP qui, je ne sais comment, arrivent à faire ce que permet cette option "rewrite_contact=yes" dans asterisk...
Donc ce parametre si on regarde sa signification d'après https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample
;rewrite_contact=yes ; necessary if endpoint does not know/register public ip:port
-
J'aime pas ce mot de tuto. >:( Dis plutôt didacticiel à la place.
Donc, mon didacticiel se trouve dans ce lien (https://lafibre.info/remplacer-sfr/utilisation-dasterisk-sous-debian-11/).
Ce fut laborieux, n'est ce pas. :)
-
Bonjour,
Excellente nouvelle ! En effet, avec le rewrite_contact, le PRACK part en fait jusqu’au proxy sortant (alors que dans le cas contraire, il aurait été dirigé vers pcgw-0006.imsgroup-019.tng1asbc05.ims.sfr.net, nom qui n’est visiblement pas résolvable avec les résolveurs de SFR). Pour info, la description de ce paramètre est là : https://docs.asterisk.org/Asterisk_20_Documentation/API_Documentation/Module_Configuration/res_pjsip/?h=#rewrite_contact
C’est un peu un bidouillage : dans un monde idéal, les URI SIP dans les en-têtes Contact devraient être joignables directement par Asterisk sans passer par des proxies.
Il se peut que la box SFR utilise des résolveurs DNS, différents de 109.0.66.10 et .20 et exclusivement dédiés à la téléphonie, pour résoudre les noms de domaine des URI SIP. Savoir de quels serveurs il s’agit nécessiterait de sniffer le trafic DNS entre la box et l’ONT.
-
et du coup comment font les Gigaset IP vu qu'ils ne passent pas par asterisk...
-
J'ai fait une pose et je reviens sur mes tests. Voilà t'y pas que j'ai de nouveaux messages d'erreurs que je n'avais pas avant :
Running as user 'asterisk'
Running under group 'asterisk'
Connected to Asterisk 20.4.0 currently running on Debian (pid = 8184)
== Contact zoiper/sip:zoiper@xxx.xxx.xxx.xxx:47865;transport=UDP;rinstance=8dbaae2d5f1d5e13 has been deleted
== Endpoint zoiper is now Unreachable
-- Added contact 'sip:zoiper@xxx.xxx.xxx.xxx:47865;transport=UDP;rinstance=78ad9dd128be5c92' to AOR 'zoiper' with expiration of 60 seconds
== Endpoint zoiper is now Reachable
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000000", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfr
-- PJSIP/sfr-00000001 is making progress passing it to PJSIP/zoiper-00000000
-- PJSIP/sfr-00000001 is ringing
[Aug 17 19:16:23] WARNING[8276][C-00000001]: channel.c:5765 set_format: Unable to find a codec translation path: (slin) -> (alaw)
[Aug 17 19:16:23] WARNING[8276][C-00000001]: indications.c:140 playtones_alloc: Unable to set 'PJSIP/zoiper-00000000' to signed linear format (write)
[Aug 17 19:16:23] WARNING[8276][C-00000001]: channel.c:4682 indicate_data_internal: Unable to handle indication 3 for 'PJSIP/zoiper-00000000'
-- PJSIP/sfr-00000001 answered PJSIP/zoiper-00000000
-- Channel PJSIP/sfr-00000001 joined 'simple_bridge' basic-bridge <d1995cdc-8642-4557-85c2-a78f05105465>
-- Channel PJSIP/zoiper-00000000 joined 'simple_bridge' basic-bridge <d1995cdc-8642-4557-85c2-a78f05105465>
-- Channel PJSIP/zoiper-00000000 left 'native_rtp' basic-bridge <d1995cdc-8642-4557-85c2-a78f05105465>
-- Channel PJSIP/sfr-00000001 left 'native_rtp' basic-bridge <d1995cdc-8642-4557-85c2-a78f05105465>
== Spawn extension (outgoing, 1023, 1) exited non-zero on 'PJSIP/zoiper-00000000'
Debian*CLI> Quel est ce codec qui me manque ?
Comme je suis derrière l'ONT, Asterisk ne voudrait-il pas que je le mette en Bridge ?
Ça mérite une médaille
En chocolat, j'espère. :)
@ X0r : Si j'ai bien compris l'usage des Proxy chez SFR, cela sert à la faturation.
Je ne vais pas trop m'investir sur ce Asterisk, l'important est que ça fonctionne sans bug.
-
Re.
Pour ton dialplan, il faut déjà créer un conexte interne pour que les postes s'apellent entre eux, exemple de ce que j'ai chez moi (numéros en 3xx, il vaudrait mieux avoir des numéros plutôt que des noms, sinon tu vas galérer) et je pense que tu peux simplement remplacer SIP par PJSIP et ovh par sfr, je crois pas que la syntaxe ai changée pour le coup (c'est déjà ça ;D)
[internal]
; On fait sonner 20 sec, avec autorisation du transfert, sinon messagerie
exten => _3XX,1,Dial(SIP/${EXTEN},20,Tt)
exten => _3XX,2,VoiceMail(${EXTEN}@internal_vm)
;Messagerie : en concordance avec SFR :D
exten => 123,1,VoiceMailMain(${CALLERID(num)}@internal_vm)
;Appels externes (je remets ici le tiens vu que c'est bon)
exten => _0[12345679]XXXXXXXX,1,Dial(PJSIP/${EXTEN}@sfr)
exten => _+33[12345679]XXXXXXXX,1,Dial(PJSIP/${EXTEN}@sfr)
exten => _1023,1,Dial(PJSIP/${EXTEN}@sfr)
include => pickup
Le pickup (répondre depuis un autre poste) :
; on tape **300 pour répondre si le 300 sonne.
[pickup]
exten => _**3XX,1,Pickup(${EXTEN:2})
exten => _**3XX,2,Hangup
; ne pas oublier le include => pickup dans [internal]
Les appels entrants :
; je suppose que le N° du gigaset est 300
[incoming]
exten => s,1,Dial(PJSIP/300,20,Tt)
exten => s,2,Voicemail(300@internal_vm)
Messgerie : /etc/asterisk/voicemail.conf Bien vérifier que tu as téléchargé les sons.
[general]
maxmsg = 10 ; Nombre max de message sur la Voicemail. Si elle est pleine, il n'est pas possible de rajouter des messages
maxsecs = 120 ; Duree max d'un message. "0" = pas de limite
minsecs = 2 ; Duree minimum d'un message
maxlogins = 3 ; Nombre max d'erreur de login
review = yes ; Permet à l'appelant de reecouter son message avant de le transmettre a la Voicmail. Accessible en terminant le message par #
saycid = yes ; Dicte le numero de l'appelant avant de jouer le message qu'il a laisse
[internal_vm]
300 => 1234,gigaset
301 => 4567,zoiper
302 => 6789,microsip
; les 4 chiffies sont les mots de passe avant d'accéder à la messagerie (facultatif)
Si ça peut t'aider ;)
-
le DialPlan de SFR récupéré au boot de la box, je ne sais pas si ça peut vous être utile...
<dialplan>
<number route="voip" length="open">00</number>
<number route="voip" length="10">01</number>
<number route="voip" length="10">02</number>
<number route="voip" length="10">03</number>
<number route="voip" length="10">04</number>
<number route="voip" length="10">05</number>
<number route="voip" length="10">06</number>
<number route="voip" length="14">07000</number>
<number route="voip" length="14">07001</number>
<number route="voip" length="14">07002</number>
<number route="voip" length="14">07003</number>
<number route="voip" length="14">07004</number>
<number route="voip" length="13">07005</number>
<number route="voip" length="13">07006</number>
<number route="voip" length="13">07007</number>
<number route="voip" length="13">07008</number>
<number route="voip" length="13">07009</number>
<number route="voip" length="10">0701</number>
<number route="voip" length="10">0702</number>
<number route="voip" length="10">0703</number>
<number route="voip" length="10">0704</number>
<number route="voip" length="10">0705</number>
<number route="voip" length="10">0706</number>
<number route="voip" length="10">0707</number>
<number route="voip" length="10">0708</number>
<number route="voip" length="10">0709</number>
<number route="voip" length="10">071</number>
<number route="voip" length="10">072</number>
<number route="voip" length="10">073</number>
<number route="voip" length="10">074</number>
<number route="voip" length="10">075</number>
<number route="voip" length="10">076</number>
<number route="voip" length="10">077</number>
<number route="voip" length="10">078</number>
<number route="voip" length="10">079</number>
<number route="voip" length="10">08</number>
<number route="voip" length="10">09</number>
<number route="voip" length="4">10</number>
<number route="voip" length="open">110</number>
<number route="voip" length="open">111</number>
<number route="voip" length="3">112</number>
<number route="voip" length="open">113</number>
<number route="voip" length="3">114</number>
<number route="voip" length="3">115</number>
<number route="voip" length="6">116</number>
<number route="voip" length="open">117</number>
<number route="voip" length="6">118</number>
<number route="voip" length="3">119</number>
<number route="voip" length="open">12</number>
<number route="voip" length="open">13</number>
<number route="voip" length="open">140</number>
<number route="voip" length="open">141</number>
<number route="voip" length="open">142</number>
<number route="voip" length="open">143</number>
<number route="voip" length="open">144</number>
<number route="voip" length="open">145</number>
<number route="voip" length="open">146</number>
<number route="voip" length="3">147</number>
<number route="voip" length="open">148</number>
<number route="voip" length="open">149</number>
<number route="voip" length="2">15</number>
<number route="voip" length="open">16</number>
<number route="voip" length="2">17</number>
<number route="voip" length="2">18</number>
<number route="voip" length="open">19</number>
<number route="voip" length="open">2</number>
<number route="voip" length="4">30</number>
<number route="voip" length="4">31</number>
<number route="voip" length="4">32</number>
<number route="voip" length="open">33</number>
<number route="voip" length="4">34</number>
<number route="voip" length="4">35</number>
<number route="voip" length="4">360</number>
<number route="voip" length="4">361</number>
<number route="voip" length="4">362</number>
<number route="voip" length="4">363</number>
<number route="voip" length="4">364</number>
<number route="voip" length="4">3650</number>
<number route="voip" length="open">3651</number>
<number route="voip" length="open">3652</number>
<number route="voip" length="4">3653</number>
<number route="voip" length="4">3654</number>
<number route="voip" length="4">3655</number>
<number route="voip" length="4">3656</number>
<number route="voip" length="4">3657</number>
<number route="voip" length="4">3658</number>
<number route="voip" length="4">3659</number>
<number route="voip" length="4">366</number>
<number route="voip" length="4">367</number>
<number route="voip" length="4">368</number>
<number route="voip" length="4">369</number>
<number route="voip" length="4">37</number>
<number route="voip" length="4">38</number>
<number route="voip" length="4">39</number>
<number route="voip" length="open">4</number>
<number route="voip" length="open">5</number>
<number route="voip" length="open">6</number>
<number route="voip" length="open">7</number>
<number route="voip" length="open">8</number>
<number route="voip" length="open">9</number>
<number route="local" length="3" serviceid="1">999</number>
<number route="local" length="4" serviceid="2">*70#</number>
<number route="local" length="4" serviceid="3">*71#</number>
<number route="local" length="4" serviceid="4">*72#</number>
<number route="voip" length="4" serviceid="5">*79#</number>
<number route="local" length="5" serviceid="6">*#70#</number>
<number route="local" length="5" serviceid="7">*#71#</number>
<number route="local" length="5" serviceid="8">*#72#</number>
<number route="voip" length="5" serviceid="9">*#79#</number>
<number route="local" length="4" serviceid="10">#70#</number>
<number route="local" length="4" serviceid="11">#71#</number>
<number route="local" length="4" serviceid="12">#72#</number>
<number route="voip" length="4" serviceid="13">#79#</number>
<number route="voip" length="open">*</number>
<number route="voip" length="open">#</number>
<number route="local" length="2" serviceid="14">R1</number>
<number route="local" length="2" serviceid="15">R2</number>
<number route="local" length="2" serviceid="16">R3</number>
<number route="local" length="2" serviceid="17">R9</number>
</dialplan>
-
je m'interroge sur l'idée d'approcher directement les ingés sfr chargés de la voip pour tenter d'éclaircir l'énorme brouillard technique sur lequel on se heurte..
ca m'a l'air tellement complexifié par la régionalisation et les proxies.. je voyais ces derniers surtout utilisés pour contacter les autres opérateurs/pstn.. peut etre que j'ai tort
-
Oui, faut contacter les ingénieurs VOIP SFR comme ça ils vont aider aux lieu de verrouiller encore plus le truc, très bonne idée ;)
-
Merci X0r pour ton aide. :) La documentation Asterisk est vraiment mal foutue.
Merci Renaud07, je fais essayer de comprendre et d'adapter ton paramétrage du dialplan.
J'aurai aimé conserver mes noms plutôt que la numérotation. Y-a-t-il moyen de considérer ces noms comme des variables et d'attribuer la numérotation suivante :
--> 301 ==> Gigatset
--> 302 ==> Zoiper
--> 303 ==> MicroSIP
Car "301@192.168.1.xx", c'est pas parlant pour moi, tandis que "Gigaset@192.168.1.xx" l'est un peu plus.
Comment enregistrer un message afin de le diffuser quand personne ne décroche le téléphone au bout de x secondes ?
Pour les appels vers l'extérieur, j'utilise ceci : "exten => _X.,1,Dial(PJSIP/${EXTEN}@sfr)".
Si j'atoute des postes vers mes téléphones, il faut que j'utilise une numérotation qui ne vient pas contrecarré ceux officiels.
Je ne peux pas utiliser le "15" qui est réservé aux pompiers, ou le "17" pour la police.
Chaque règle doit être indépendante les unes deux autres, sinon conflit d'accès. Est-ce bien cela ?
Pour les contextes, j'aurai aimé :
--> incoming : appels entrants depuis internet
--> outgoing : appels sortants vers internet
--> internal : appels interne à mon réseau local
De ce fait, je ne touche pas à ce que j'ai écrit pour "incomming" & "outgoing".
Ou suis-je obligé de faire un contexte par téléphone ? Ce qui donne :
--> incoming : appels entrant depuis internet
--> Gigaset : appels sortant depuis le Gigaset
--> Zoiper : appels sortant depuis le Zoiper
--> MicroSIP : appels sortant depuis le MicroSIP
Ce qui permet de garder un certaine souplesse en faisant du spécifique pour chaque téléphone.
et du coup comment font les Gigaset IP vu qu'ils ne passent pas par asterisk...
C'est un paramétrage qui est déjà implémenté dans le téléphone VOIP/SIP, sans pour autant être un serveur Asterisk.
Avec ton MicroSIP et WireShark, peux tu m'indiquer le paramétrage qui est envoyé vers SFR.
Je croyais l'avoir résolu mais j'ai à nouveau des problèmes d'authentification.
[Aug 18 10:55:21] WARNING[22780]: res_pjsip_outbound_authenticator_digest.c:507 digest_create_request_with_auth: Endpoint: 'sfr': No auth objects matching realm(s) '' from challenge found.
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1023@outgoing:2] Hangup("PJSIP/zoiper-00000000", "") in new stack
== Spawn extension (outgoing, 1023, 2) exited non-zero on 'PJSIP/zoiper-00000000'
-- Executing [1023@outgoing:1] Dial("PJSIP/zoiper-00000002", "PJSIP/1023@sfr") in new stack
-- Called PJSIP/1023@sfrAprès plusieurs tentatives infructueuses, ça passe, puis ça revient.
Je ne comprends pas pourquoi cette erreur est aléatoire.
-
Pour décorréler les numéros des noms, en théorie il existe le paramètre : alternateexts= (https://github.com/asterisk/asterisk/blob/master/configs/samples/users.conf.sample)mais le problème, c'est que je n'arrive pas à le faire fonctionner (j'aimerais aussi m'en servir)... Je me fait jeter avec le message Purely numeric hostname (XXX), and not a peer--rejecting! J'ai eu beau chercher, je ne sais pas vraiment ce qui coince et il n'y a pas d'explication claire sur les forums... Faut que je regarde du côté de pjsip voir si ça marcherait pas mieux, là c'est pour chan_sip.
Mais le gros problème des extensions avec des lettres, c'est que sur un vrai téléphone tu ne peux taper que des chiffres, donc avec ton gigaset, ça ne fonctionnera pas. Pour le choix des numéros en effet, il ne faut pas empiéter sur le public. Le 3xx convient bien. Tout comme une extension à 4 chiffres genre 6xxx
Comment enregistrer un message afin de le diffuser quand personne ne décroche le téléphone au bout de x secondes ?
Quand quelqu'un t’appelle de l'extérieur ? Si tu veux un truc personnalisé tu peux simplement enregistrer ce que tu veux (genre avec audacity) et le faire jouer avant la messagerie. Ou sinon la messagerie elle même propose d’enregistrer le message/nom prénom qu'on veut.
Pour les contextes, j'aurai aimé :
--> incoming : appels entrants depuis internet
--> outgoing : appels sortants vers internet
--> internal : appels interne à mon réseau local
De ce fait, je ne touche pas à ce que j'ai écrit pour "incomming" & "outgoing".
Ou suis-je obligé de faire un contexte par téléphone ?
Les 3 contextes suffisent, pas besoin de complexifier inutilement. D’ailleurs, tu ne confondrais pas avec les templates qui permettent d'avoir un paramétrage défini sans devoir le réécrire pour chaque user ? Genre les codecs, le nat actif ou non...
EDIT : Dans l'absolu, tu peux faire un contexte pour chaque tel, genre un peut appeler les portables, mais pas les autres... mais honnêtement ce genre de conf se voit plus en entreprise pour pas que les employés appellent n'importe qui (ou des numéros surtaxés) avec le numéro du boulot par ex. Dans ton cas, ça n'a pas grand intérêt.
-
Merci Renaud07, mais pour l'instant je me concentre sur les Warning que j''ai dans la console Asterisk.
Je reviendrai ultérieurement sur la configuration du fichier extensions.conf.
-
Mais le gros problème des extensions avec des lettres, c'est que sur un vrai téléphone tu ne peux taper que des chiffres, donc avec ton gigaset, ça ne fonctionnera pas. Pour le choix des numéros en effet, il ne faut pas empiéter sur le public. Le 3xx convient bien. Tout comme une extension à 4 chiffres genre 6xxx
Quand quelqu'un t’appelle de l'extérieur ? Si tu veux un truc personnalisé tu peux simplement enregistrer ce que tu veux (genre avec audacity) et le faire jouer avant la messagerie. Ou sinon la messagerie elle même propose d’enregistrer le message/nom prénom qu'on veut.
Les 3 contextes suffisent, pas besoin de complexifier inutilement. D’ailleurs, tu ne confondrais pas avec les templates qui permettent d'avoir un paramétrage défini sans devoir le réécrire pour chaque user ? Genre les codecs, le nat actif ou non...
c'est un ppeu ce que j'ai sur un gigaset, bien que n'ayant pas sfr, pour mieux comprendre l'usage du sip sur ces appareils
il a été fabriqué quqelques années après les vrais appareils sip linksys qui le cotoient ici, ces derniers permettant les appels vers tous types de caractères, car ils sont faits pour le sip. Or, les tels gigaset, c'est :
- une ligne fixe ordinaire
- une ligne sip, limitée aux appels émis vers les numéros uniquement (donc par ex chez ippi, un compte peut se voir attribuer le DID 8897611XX, qui permet de recevoir des appels gratos via SIP. Linphone fait un peu différemment : pas de DID numérique (donc softphone obligatoire) ni d'appels vers le réseau ordinaire (pstn/pots). Mais pour cela il a fallu configurer les préfixes en indiquant dans la base gigaset : "889" comme préfixe vers la ligne SIP ippi. Or, celui qui sait pas ça, en a pour des heures d'arrachage de cheveux pour que cela fonctionne. Plus surprenant, les appels provenant de toutes adresses SIP (DID comme adresse@domain.net) sont acceptés ; et donc gigaset permet de recevoir des appels en provenance d'un compte linphone.. sans pouvoir en émettre vers ces comptes ;)
- un accès au réseau gigaset.net, que j'espère pouvoir tester bientot : énormément de "comptes" référencés, sur un système que la doc indique fonctionner sur xmpp, mais complètement fermé aux non gigaset.
c'est tout ce que j'ai pu tester pour le moment. Bien que le sip ouvert aurait été très prometteur (appeler des contacts SIP gratos depuis le pstn est possible), dommage qu'il soit pas plus adopté que ca par le public et les orgaisations..
-
Pour le gigaset, je disais ça de façon générale. Sur un téléphone classique on tape que des chiffres, même si les vrais téléphones SIP permettent de taper une adresse avec des lettres, c'est laborieux... Je peux le faire aussi sur le mien, mais j'ai préféré mettre des numéros.
Taper 3 chiffres au lieu d'un user, le choix est vite fait :P En plus le mien a les touches de raccourci, c'est encore plus pratique, un clic et ça appelle (avec en plus la led de signalisation vert/rouge selon si c'est occupé ou en train de sonner, très pratique également).