Acheminement des requêtes Asterisk

[Hamza Khait]

Bonjour à tous,

Suite à un dysfonctionnement réseau au niveau d'Asterisk. Je me posais des questions sur l'acheminement exact de ses requêtes (REGISTER, Appels entrants, Appels sortants...).

Voici l'architecture de mes machines :

Quand je lance Asterisk. la requête REGISTER ne marche pas pour certains SIP providers, j'obtiens WRONG PASSWORD à chaque tentative. Et ça marche une fois sur 10 pour freephonie.fr, dans la plupart des cas j'obtiens : 

Probably a DNS error for registration to xxxxx...@freephonie.net, trying REGISTER again (after 20 seconds)

Registration for 'xxxxx...@freephonie.net' timed out, trying again

Voici donc mes question : 

1. Lesquels de ces acheminements sont justes ? :
• Asterisk envoie une REGISTER request ==> Routing ==> Routeur ==> SIP provider
• Asterisk envoie une REGISTER request ==> Routeur ==> SIP provider (Dans ce cas, faut-il ajouter les paramètres du NAT dans sip.conf?)
• Un appel sortant (machine DEV) ==> Gateway ==> Routing ==> Routeur ==> SIP provider
• Un appel sortant (machine DEV) ==> Gateway ==> Routeur ==> SIP provider
• Un appel entrant ==> Routeur ==> Routing ==> Gateway ==> DEV
• Un appel entrant ==> Routeur ==> Gateway ==> DEV (dans ce cas pourquoi on a bindaddr=adresse_gateway_VPN?

En vous remerciant,

Cordialement,

Hamza KHAIT

[Arnaud MORIN]

Finalement ta question c'est est ce que les requêtes SIP passent systématiquement par routing ou pas lorsque la gateway entre en jeu ?

Bonne question!
Nous on utilise le plus souvent un T2, on a donc pas ce problème de routage SIP pour les providers.

Je vais regarder plus en détails quand j'aurai un peu de temps, mais de mémoire on faisait en sorte que la GW envoit son traffic SIP directement au provider SIP.

Tu peux le voir facilement avec tshark / wireshark.

Arnaud.

De memoire

[Hamza Khait]

Bonjour Arnaud,

Merci pour ta réponse. Effectivement la Gateway envoie le traffic au SIP provider sans passer par la Routing.

Maintenant j'arrive à me connecter avec mon compte SIP. Sauf que rien ne se passe par la suite quand j'appelle mon numéro.

Le traffic arrive bien jusqu'à la machine DEV mais pas d'audio et même le $call->Hangup(); de mon projet ne marche pas.

Dans les logs tout se passe bien sauf qu'au bout d'un moment j'ai ça : 

chan_sip.c:4175 retrans_pkt: Retransmission timeout reached on transmission 20084bbe61984ccf...@109.190.122.74:5060 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Packet timed out after 31999ms with no response

Really destroying SIP dialog '20084bbe61984ccf...@109.190.122.74:5060' Method: INVITE

Vraiment bizarre cet Asterisk..

Hamza

[Arnaud MORIN]

Hello,

Essaye de prendre des traces avec wireshark / tshark et de nous les envoyer, pas simple de debuger à l'aveugle :p

Arnaud

[Hamza Khait]

Hello Arnaud,

Ci-joint, les resultats de rasterisk -vvv et tshark sur les deux machines DEV et Gateway lors d'un appel entrant.

Ma gateway est derrière un NAT donc j'ai ajouté les paramètres externip, localnet et nat dans sip.conf.

Hamza

On Wednesday, 20 April 2016 00:04:07 UTC+2, Arnaud wrote:

Hello,

Essaye de prendre des traces avec wireshark / tshark et de nous les envoyer, pas simple de debuger à l'aveugle :p

Arnaud

2016-04-15 14:37 GMT+02:00 Hamza Khait <hamza...@gmail.com>:

Bonjour Arnaud,

Merci pour ta réponse. Effectivement la Gateway envoie le traffic au SIP provider sans passer par la Routing.

Maintenant j'arrive à me connecter avec mon compte SIP. Sauf que rien ne se passe par la suite quand j'appelle mon numéro.

Le traffic arrive bien jusqu'à la machine DEV mais pas d'audio et même le $call->Hangup(); de mon projet ne marche pas.

Dans les logs tout se passe bien sauf qu'au bout d'un moment j'ai ça : 

chan_sip.c:4175 retrans_pkt: Retransmission timeout reached on transmission 20084bbe61984ccf63f0eef5252f866...@109.190.122.74:5060 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Packet timed out after 31999ms with no response

Really destroying SIP dialog '20084bbe61984ccf63f0eef5252f86...@109.190.122.74:5060' Method: INVITE

[Arnaud MORIN]

Tu as un probleme de routage SIP.

Je pense que 0.2 = routing, 0.3 = dev, 0.5 = gateway, n'est ce pas?

Si c'est le cas, on voit que gateway envoit la requete à routing.
Routing traduit l'appel en translatant le numéro vers VOCALAPP et transmet à dev.

Dev répond 200 OK  à routing.

Routing transmet le 200 OK à gateway.

Gateway répond ACK à routing.

Mais routing ne retransmet pas le ACK à dev.

Ton probleme vient de là.

Sur routing, c'est OpenSIPS qui gere ça.

De mémoire, il log dans /var/log/syslog.

Essaye de voir ce qui s'y passe.

Au besoin, tu vas peut etre devoir jouer avec le module nat d'OpenSIPS.
http://www.opensips.org/html/docs/modules/1.8.x/nathelper.html

Bon courage,

Arnaud.

2016-04-20 12:07 GMT+02:00 Hamza Khait <hamza...@gmail.com>:

Hello Arnaud,

Ci-joint, les resultats de rasterisk -vvv et tshark sur les deux machines DEV et Gateway lors d'un appel entrant.

Ma gateway est derrière un NAT donc j'ai ajouté les paramètres externip, localnet et nat dans sip.conf.

Hamza

On Wednesday, 20 April 2016 00:04:07 UTC+2, Arnaud wrote:

Hello,

Essaye de prendre des traces avec wireshark / tshark et de nous les envoyer, pas simple de debuger à l'aveugle :p

Arnaud

2016-04-15 14:37 GMT+02:00 Hamza Khait <hamza...@gmail.com>:

Bonjour Arnaud,

Merci pour ta réponse. Effectivement la Gateway envoie le traffic au SIP provider sans passer par la Routing.

Maintenant j'arrive à me connecter avec mon compte SIP. Sauf que rien ne se passe par la suite quand j'appelle mon numéro.

Le traffic arrive bien jusqu'à la machine DEV mais pas d'audio et même le $call->Hangup(); de mon projet ne marche pas.

Dans les logs tout se passe bien sauf qu'au bout d'un moment j'ai ça : 

chan_sip.c:4175 retrans_pkt: Retransmission timeout reached on transmission 20084bbe61984ccf...@109.190.122.74:5060 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Packet timed out after 31999ms with no response

Really destroying SIP dialog '20084bbe61984ccf...@109.190.122.74:5060' Method: INVITE

[Hamza Khait]

Bonjour Arnaud,

Je me permets de revenir sur ce sujet suite à plusieurs debug et une longue analyse réseau sur la plateforme. En effet, je me suis posé beaucoup de questions sur le routage SIP sur Emerginov. 

Pourquoi le traffic RTP (20000-20999) est redirigé vers Routing et pas Gateway qui fait le relais avec l'opérateur téléphonique? D'ailleurs quand je regarde la conf d'Asterisk (/etc/asterisk/rtp.conf) les ports RTP sont 10000-20000.

Tous mes serveurs (Gardien, Dev, Content, Gateway, Routing) sont derrière un NAT. Cela nécessite l'ajout des paramètres "externip" et "localnet" dans sip.conf de la GW. y-a-t il d'autres conf à faire dans ce cas au niveau d'opensips et Asterisk de DEV ?

Malheusement, malgré cette analyse réseau et les redirections iptables (qui sont bonnes je suppose), je ne parviens toujours pas à effectuer des appels Emerginov ==> Téléphone et pas d'audio dans l'autre sens.

Hamza

chan_sip.c:4175 retrans_pkt: Retransmission timeout reached on transmission 20084bbe61984ccf63f0eef5252f866...@109.190.122.74:5060 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Packet timed out after 31999ms with no response

Really destroying SIP dialog '20084bbe61984ccf63f0eef5252f86...@109.190.122.74:5060' Method: INVITE

[Arnaud MORIN]

Plop,

Le RTP sur routing c'est pour les appels SIP <--> SIP, sans passage vers la GW.

Sur la GW il y aussi besoin de RTP, qu'on a mis 10000 a 20000.

Le NAT c'est la mauvaise idee de ton architecture. Ca complique tes flux, ca pose tout un tas de probleme.

Les preconisations sont de pas avoir de NAT. En plus, OpenSIPS reagit assez mal au NAT.

Asterisk s'en sort un peu mieux mais c'est pas ouf. :/

chan_sip.c:4175 retrans_pkt: Retransmission timeout reached on transmission 20084bbe61984ccf...@109.190.122.74:5060 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

Packet timed out after 31999ms with no response

Really destroying SIP dialog '20084bbe61984ccf...@109.190.122.74:5060' Method: INVITE

[Hamza Khait]

Hello Arnaud,

Hum! je comprends mieux maintenant. 

Enlever le NAT signifie que je devrais donner une IP publique à ma machine Routing et faire d'autres modifs au niveau de la gateway. Y aura un peu de travail à faire :-)

Merci pour les remarques.

Hamza KHAIT