PDA

Voir la version complète : Appel sortant couper par trixbox, suivant le matériel utiliser.



primax
05/08/2011, 22h12
Bonjour,

d'avance merci pour votre aide.

Trixbox sur serveur distant derriere firewall

mon extension 100 parametrer sur smartphone et appli sipdroid aucun soucis que se soit sur appel entrant et sortant

par contre meme extensions meme parametre sur cisco spa525G2 et Xlite , appel entrant ok plus 1h sans coupure mais en appel sortant au bout de 20sec pile sa coupe:

log asterisk:


Called 200
-- SIP/200-00000208 is ringing
-- SIP/200-00000208 answered SIP/100-00000207
-- Executing [h@macro-dial:1] Macro("SIP/100-00000207", "hangupcall") in new stack
-- Executing [s@macro-hangupcall:1] GotoIf("SIP/100-00000207", "1?skiprg") in new stack
-- Goto (macro-hangupcall,s,4)
-- Executing [s@macro-hangupcall:4] GotoIf("SIP/100-00000207", "1?skipblkvm") in new stack
-- Goto (macro-hangupcall,s,7)
-- Executing [s@macro-hangupcall:7] GotoIf("SIP/100-00000207", "1?theend") in new stack
-- Goto (macro-hangupcall,s,9)
-- Executing [s@macro-hangupcall:9] Hangup("SIP/100-00000207", "") in new stack

je suis un peu perdu ...j ai changer le port sip 5060 vers 443 ca passe bien
les ports rtp mis de 10000 a 50000 , et ouvert sur le firewall mais rien y fait

si quelqu 'un a une idée je suis preneur.

Merci

primax
08/09/2011, 23h49
Si quelqu un a une idée je suis preneur, toute les idée sont bonne a prendre ...

apres avoir parcouru google .. mis a jour la box recreer les trunks , .. idem

je dois manquer quelques chose mais quoi ????

apparement la ligne exact au moment du plantage est :


== Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/300-00000905' in macro 'hangupcall'
== Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/300-00000905'

et le téléphone de l'appelant reste avec le compteur qui defile , ... :confused:

Merci

jean
09/09/2011, 14h59
la coupure apres 20 sec pile est symptomatique de l acquittement du ok notifiant le decroche qui n arrive pas. donc soit le ok n arrive pas au poste soit le ack n arrive pas au serveur.
ca peut etre un firewall qui se referme trop vite, ou un autre pbm reseau....

j. mobile....

primax
10/09/2011, 11h23
Merci de prendre du temps pour repondre a mon probleme

je ne pense pas que se soit un delai car sipdroid passe en wifi et les delai etant beaucoup plus long le firewall déclencherai aussi je pense .

je partirai plus pour une reponse au mauvais endroit due au NAT ...
voici ce que je remarque tous les tel se connecte bien sur le port demander en configuration sauf le portable avec sipdroid qui lui fonctionne ( ext 100)

188


même si je modifie la configuration puis ouvre les port sur le firewall du serveur on arrive au même point
par contre sipdroid lui je n ai pas configurer ce port ni même ouvert sur le firewall et tout passe ...

comment faire pour vérifier qui ne fait pas le bon transfert des infos du décroché ?

fastm3
10/09/2011, 15h24
Deja essaie de preciser ton archi reseau.
Tu sembles avoir un serveur ( derriere nat ? , routeur ), ip fixe.
Tu accedes a distance avec des extensions : derriere nat, derriere routeur.
Plusieurs extensions derriere un nat ? A priori oui mais c'est seulement maintenant qu'on le devine.
Tu parles de firewall , s'agit t'il d'un firewall routeur coté serveur, coté extensions, ou iptables sur le serveur ?
Asterisk ecoute sur 5060 ou 443 ?

Tu parles d'un acces avec un mobile, acces connecté par wifi , 3g ? De quel coté , de ou ?
Bref, trop d'inconnu , pour qu'on puisse te repondre car trop d'hypotheses car tu ne donnes jamais d'elements tres precis.
En fonction des reponses, on cherchera en effet du coté sip.conf, cote config endpoint ou coté config reseau.

Ca peut etre effectivement un pb routeur qui ferme les ports un peu trop vite comme l'indique Jean. Je pencherai celui coté extensions et non serveur.

Fastm3.

primax
11/09/2011, 13h23
Trixbox derriere firewall par iptable ( shorewall )
port 443 rediriger vers 5060 de trixbox
port de chaque extension sip rediriger vers le port trixbox tout en udp
port udp 38001 à 39000 ridiriger vers la box aussi
rtp.conf modifier avec les derniers ports cités

et les telephones architecture classique freebox en mode routeur + switch
tel HTC Desire avec appli android en wifi , qui fonctionne en envoie et réception
tel Cisco SPA525G2, qui fonction en réception et 20 sec en envoie que se soit en wifi ou en filaire ...
et softphone Xlite 4 sur Win7 64bit en wifi et filaire idem fonctionne 20s en envoie puis coupe et reception pas de probleme.

sip_nat.conf

nat=yes
externhost=pbx.meXXXXXX.fr
externip=88.190.XXX.XX
localnet=192.168.1.0/255.255.255.0
externrefresh=25

J ai mis un maximum d'info merci , n'hesiter pas a me dire si il en manque

Reaper
11/09/2011, 15h49
Bonjour, vous avez fait plusieurs erreurs:


port 443 rediriger vers 5060 de trixbox


Si c'est un trigger, et asterisk est encore bindport=5060, dans les messages sip il va demander de le contacter en 5060, et donc une partie de message peux être perdue.


port de chaque extension sip rediriger vers le port trixbox tout en udp


Je suppose que vous avez vu le output de commande "sip show peers"

En realité la liste de ports dedans es tune liste de ports distants de peers, pas la peine de les renvoyer vers trixbox.


rtp.conf modifier avec les derniers ports cités

Même chose ici, ça ne sert a rien. Il vous faut renvoyer la liste de ports suivante, la valeur de bindport= (vous pouvez changer) et le range de rtp.conf, vous pouvez réduire par exemple, 10000-10500, si votre souci c'es tla sécurité je vous assure que réduire les ports ça n'aide pas, c'est le même daemon, changement de bindport est conseillé


Il vous faut faire un simple sip debug sur le peer avec le défaut, je suppose que c'est un paquet sip qui n'arrive pas à joindre le téléphone <> asterisk.
Et pour shorewall il suffit de faire "tail -f /var/log/messages | grep DROP" pour voir les paquets bloques.

primax
11/09/2011, 18h59
Merci beaucoup , je pense que ca avance

pour le rtp je savais suivant le nombres de connexion simultanées ..

j ai modifier le bindport en 443 ...ok
j ai supprimer les regles pour les extensions

et voila le résultat des log shorewall

Sep 11 18:49:12 fwm kernel: [15839321.157577] Shorewall:net2fw\:DROP:IN=eth0 OUT= MAC=00:50:56:00:01:1f:00:25:45:f6:94:XX:XX:XX SRC=82.239.XXX.XX DST=88.190.2XX.XX LEN=440 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=5112 DPT=5060 LEN=420

donc si j'interprete bien le firewall bloque les paquets provenant des tel normal vu que j ai supprimer les regles pour les ports ...

shorewall pas de trigger mais DNAT:
DNAT net loc:192.168.1.100:443 udp 443
#DNAT net loc:192.168.1.100 udp 5100
#DNAT net loc:192.168.1.100 udp 5110:5112
#DNAT net loc:192.168.1.100 udp 5200
#DNAT net loc:192.168.1.100 udp 5300
DNAT net loc:192.168.1.100 udp 38001:39000


le sip show peers me marque UNREACHABLE maintenant sauf l extension qui fct et qui a le port 43224 mais d'ou vient ce port ??

pour le sip debug, je n'ai pas su faire la commande.

Reaper
11/09/2011, 20h36
Suivez l'ensemble de mes instructions, vos réponses sont dans mon message.

primax
11/09/2011, 21h35
Le bindport je l avait mis dans sip_custom.conf mais apparment il le prenait pas pour cela qu il continuait envoyer sur 5060 mais maintenant en le mettant dans sip_general.conf bindport=443 plus de paquet rejeter mais aucune extension ne se connecte plus de tel ni envoie ni reception ??

Reaper
11/09/2011, 23h10
A votre avis pourquoi ? (ils se connectent sur quel port vos téléphones ?!)

primax
12/09/2011, 08h00
Tous sur iptrixbox:443 ...mais aucun ne s'enregistre et aucun paquet drop ....

mauvais endroit pour le bindport ...car meme en mettant bindport:5060 plus rien ne fonctionne avec l'ancienne configuration.

est ce toutes les extensions doivent s'enregistrer sur le même port ?

primax
12/09/2011, 20h57
Bonsoir,

Encore merci Reaper d'avoir pris du temps pour me répondre.

Plusieurs soucis restaient , le bindport était pas pris en compte car dans un autre fichier subsistait un bindport mal paramétrer , en supprimant tout il envoyait bien les infos sur le 443 et les tels se connectaient de nouveau.
j'ai modifier le 443 car je vois de nombreux scan ce faire à l'epoque j avais mis 443 tcp car les connections forfait data n'etait pas bloquer sur ce port.

@+