impossible d'enregistrer l'utilisateur SIP sur red5server, en utilisant red5phone

13

Je démarre le red5,

puis je lance red5phone

J'essaie d'enregistrer un utilisateur SIP, les détails que je fournis sont

    nom d'utilisateur = 999999
    mot de passe = ****
    ip = asteriskserverip

Et j'ai

- Contact d'inscription - sip: 999999@127.0.0.1: 5072

Le bon contact pourrait être

- Enregistrement du contact - sip: 99999 @ asteriskserverip

Voici le journal:

SipUserAgent - listen -> Init...
Red5SIP register
[SIPUser] register
RegisterAgent: Registering contact <sip:99999@127.0.0.1:5072> (it expires in 3600 secs)
RegisterAgent: Registration failure: No response from server.
[SIPUser] SIP Registration failure Timeout
RegisterAgent: Failed Registration stop try.
Red5SIP Client leaving app 1
Red5SIP Client closing client 35C1B495-E084-1651-0C40-559437CAC7E1
Release ports: sip port 5072 audio port 3002
Release port number:5072
Release port number:3002
[SIPUser] close1
[SIPUser] hangup
[SIPUser] closeStreams
RTMPUser stopStream
[SIPUser] unregister
RegisterAgent: Unregistering contact <sip:99999@127.0.0.1:5072>
SipUserAgent - hangup -> Init...
SipUserAgent - closeMediaApplication -> Init...
[SIPUser] provider.halt
RegisterAgent: Registration failure: No response from server.
[SIPUser] SIP Registration failure Timeout

Veuillez me faire savoir si je fais quelque chose de mal.

— Mark Henderson
source

D'une manière ou d'une autre, cette question a obtenu 11 votes positifs. Quelle est exactement la question de programmation ici?

— Duck

Cette question d'administrateur système :)

— Vitaly Nikolaev

2

Ce que je suggère de faire, c'est de faire une capture de paquets à la fois côté téléphone et côté serveur, puis d'analyser les captures à l'aide de WireShark.

Wireshark a une interprétation exceptionnellement bonne du trafic VoIP et décompose les paquets SIP pour vous en morceaux faciles à lire.

À partir de là, vous pouvez savoir si votre serveur STUN est incorrect (si vous utilisez STUN), ou s'il se passe quelque chose de bizarre avec le paquet de connexion, puis l'utiliser pour affiner la situation.

La raison de l'exécution de la capture aux deux extrémités, c'est que j'ai vu des pare-feu bien intentionnés "SIP-Aware" manipuler les paquets SIP de manière incorrecte, ce qui n'a causé aucun mal de tête, mais je pouvais alors dire que les paquets entrant dans le pare-feu étaient différent de ce qui quittait le pare-feu, qui était un cadeau.

— Mark Henderson
source

2

La capture de paquets (thsark / ngrep) contient les réponses que vous recherchez.

Je dirais que le serveur ne reçoit pas le paquet SIP pour l'enregistrement ou que le client ne peut pas recevoir la réponse, à en juger par

'RegisterAgent: échec d'enregistrement: aucune réponse du serveur.'

Vérifiez cela en utilisant tshark / ngrep / tcpdump sur le serveur sur lequel vous essayez de vous inscrire. Si vous le voyez atterrir sur le serveur mais que le serveur ne répond jamais, vérifiez ses fichiers journaux. Vérifiez qu'il n'y a pas de règles de pare-feu sur le serveur, bloquez-le. Il apparaîtra en reniflant mais l'application ne répondra pas.

Le SIP standard sera sur le port 5060, probablement UDP mais parfois TCP (je vous regarde Microsoft ...).

Exemples:

tshark -i eth0 "port 5060"
ngrep -q -W byline "" "port 5060"
tcpdump "port 5060"

ngrep est pratique si vous avez beaucoup d'autres trafics SIP valides mais que vous devez en lire rapidement une partie.

ngrep -q -W byline "5025851212" "port 5060"

Par exemple, cela rechercherait un numéro de téléphone spécifique, ou

ngrep -I CAPTURED.PCAP -q -W byline "CallID@Here.com" "port 5060"

un identifiant d'appel spécifique à l'intérieur d'un fichier précapturé: CAPTURED.PCAP

— Essobi
source