Bien vu ! je viens de faire une capture depuis le routeur, et pas de status 180 Ringing et encore moins de 200 OK



Et en parallele sur les requettes DNS capturées, puisque c'es de l'UDP, je vois ceci qui m'interpelle :

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.

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 :

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 ?

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.

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,

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 :

Code: [Sélectionner]

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.