jean
29/01/2015, 15h26
bonjour
je vois régulièrement des messages qui ne comprennent pas pourquoi il n'y a pas de son lors d'un appel.... voici quelques explications, à lire bien au calme:
1/ le nat
https://fr.wikipedia.org/wiki/Network_address_translation
en gros, dans le cas typique d'une installation avec une live/b/free box, l'installation a une seule adresse ip publique (donc, coté WAN, wide area network). chaque pc/tel/etc... connecté à cette box reçoit une ip privée, dans le LAN (local area network). ces adresses sont souvent de la forme 192.168.1.x (ou 192.168.x.y).
quand un pc sur lan accède, par exemple, à un site web, la box assigne un numéro de port aléatoire à cette demande, et l'envoie au serveur avec son ip publique
ex (format ip:port)
pc : 192.168.1.10:1234 veut joindre 1.2.3.4:80 (ou un quelconque serveur)
box : mon.ip.pub.lique:4567 veut joindre 1.2.3.4:80 et mémorise cette association
serveur: recoit une demande de mon.ip.pub.lique:4567
serveur: repond à mon.ip.pub.lique:4567
box: retrouve l'ip locale associée à mon.ip.pub.lique:4567 , donc , envoie à 192.168.1.10:1234
tout ca se fait automatiquement - comme le lan initie la connexion, la box (le routeur en fait) mémorise tout
2/ et le sip alors ?
ben, pour le sip, ca marche pareil - rappel: le sip, c'est la signalisation, pas l'audio
mais, quand on établit un appel, disons A -> B, A envoie un message invite, et indique dans le paquet sip à quelle ip il faut envoyer le media (RTP). c'est pratique, ca permet d'avoir une machine ou plusieurs machines traitant le média, pour une faisant la sig (ou d'avoir des configs bien compliquées). mais souvent, c'est la même machine qui traite le media ET la sig - sip et RTP.
probleme... comme le pc ne connait que son ip privée (192.168....), il met cette adresse, et le serveur distant répond en envoyant le flux à cette adresse. comme ils ne sont pas sur le meme lan, ben ca marche pas.
note: lorsque A envoie l'invite, il met donc son adresse dans le paquet - après un ack, et eventuellement un ringing, B répond avec un simple message OK pour dire que c'est décroché. dans ce message OK, il indique AUSSI SA PROPRE adresse ip - le problème est donc des deux coté si les deux cotés sont nattés
3/ les solutions
y'en a plusieurs
- le stun: le client interroge un serveur externe (stun server) qui lui répond en donnant son adresse publique. il la met comme adresse de media
- SIP ALG - certaines box/routeur ont une fonction alg, qui inspecte les paquets, et fait cette translation. mais souvent, c'est mal fait et ca casse le sip, et pas grand chose ne marche. a desactiver systematiquement
- en asterisk pur:
pour les clients
l'option nat=force_rport (anciennement nat=yes), permet de forcer asterisk à ignorer l'adresse dans le invite, et à envoyer le media sur l'@ ip ou il a reçu l'invite
et si le serveur est lui meme derrière un nat:
le paramètre localnet permet de dire quelles @ ip sont en local. si asterisk doit envoyer du media à une adresse qui rentre dans ce masque, il ne change rien. en revanche, si le destinataire ne match pas, il indique que son adresse pour le media est externip (ou externhost).
4/ comment debugger
une facon simple,
rtp set debug on
sip set debug on
après, on regarde defiler les messages RTP "Got" ou "Sent RTP packet to" - si on voit des adresses locales et que le client est distant, pas de bol (attention, quand on appelle d'un poste sur le lan, via asterisk, vers un poste hors lan, on a deux appels, donc deux jeux de traces qui se mélangent)
je vois régulièrement des messages qui ne comprennent pas pourquoi il n'y a pas de son lors d'un appel.... voici quelques explications, à lire bien au calme:
1/ le nat
https://fr.wikipedia.org/wiki/Network_address_translation
en gros, dans le cas typique d'une installation avec une live/b/free box, l'installation a une seule adresse ip publique (donc, coté WAN, wide area network). chaque pc/tel/etc... connecté à cette box reçoit une ip privée, dans le LAN (local area network). ces adresses sont souvent de la forme 192.168.1.x (ou 192.168.x.y).
quand un pc sur lan accède, par exemple, à un site web, la box assigne un numéro de port aléatoire à cette demande, et l'envoie au serveur avec son ip publique
ex (format ip:port)
pc : 192.168.1.10:1234 veut joindre 1.2.3.4:80 (ou un quelconque serveur)
box : mon.ip.pub.lique:4567 veut joindre 1.2.3.4:80 et mémorise cette association
serveur: recoit une demande de mon.ip.pub.lique:4567
serveur: repond à mon.ip.pub.lique:4567
box: retrouve l'ip locale associée à mon.ip.pub.lique:4567 , donc , envoie à 192.168.1.10:1234
tout ca se fait automatiquement - comme le lan initie la connexion, la box (le routeur en fait) mémorise tout
2/ et le sip alors ?
ben, pour le sip, ca marche pareil - rappel: le sip, c'est la signalisation, pas l'audio
mais, quand on établit un appel, disons A -> B, A envoie un message invite, et indique dans le paquet sip à quelle ip il faut envoyer le media (RTP). c'est pratique, ca permet d'avoir une machine ou plusieurs machines traitant le média, pour une faisant la sig (ou d'avoir des configs bien compliquées). mais souvent, c'est la même machine qui traite le media ET la sig - sip et RTP.
probleme... comme le pc ne connait que son ip privée (192.168....), il met cette adresse, et le serveur distant répond en envoyant le flux à cette adresse. comme ils ne sont pas sur le meme lan, ben ca marche pas.
note: lorsque A envoie l'invite, il met donc son adresse dans le paquet - après un ack, et eventuellement un ringing, B répond avec un simple message OK pour dire que c'est décroché. dans ce message OK, il indique AUSSI SA PROPRE adresse ip - le problème est donc des deux coté si les deux cotés sont nattés
3/ les solutions
y'en a plusieurs
- le stun: le client interroge un serveur externe (stun server) qui lui répond en donnant son adresse publique. il la met comme adresse de media
- SIP ALG - certaines box/routeur ont une fonction alg, qui inspecte les paquets, et fait cette translation. mais souvent, c'est mal fait et ca casse le sip, et pas grand chose ne marche. a desactiver systematiquement
- en asterisk pur:
pour les clients
l'option nat=force_rport (anciennement nat=yes), permet de forcer asterisk à ignorer l'adresse dans le invite, et à envoyer le media sur l'@ ip ou il a reçu l'invite
et si le serveur est lui meme derrière un nat:
le paramètre localnet permet de dire quelles @ ip sont en local. si asterisk doit envoyer du media à une adresse qui rentre dans ce masque, il ne change rien. en revanche, si le destinataire ne match pas, il indique que son adresse pour le media est externip (ou externhost).
4/ comment debugger
une facon simple,
rtp set debug on
sip set debug on
après, on regarde defiler les messages RTP "Got" ou "Sent RTP packet to" - si on voit des adresses locales et que le client est distant, pas de bol (attention, quand on appelle d'un poste sur le lan, via asterisk, vers un poste hors lan, on a deux appels, donc deux jeux de traces qui se mélangent)