Voir la version complète : ISDN France Telecom - OctoBRI
Bonjour à tous,
je suis confronté à un problème plus que bizarre.
J'ai un serveur Asterisk en 1.2.4 qui fonctionne correctement avec des téléphones IP.
J'y ai ajouté une carte OctoBRI pour y connecter quelques lignes numéris.
Je pense que mes configs du zaptel.conf et du zapata.conf sont OK (Cf ci-dessous)
Cela dit, il m'est impossible de recevoir un appel :
- rien ne s'affiche dans la console Asterisk, même pas une petite détection d'appel et je suis automatiquement jeté lorsque j'appelle le serveur Asterisk via cette ligne ISDN
De même, il m'est impossible d'emettre un appel. J'ai un Hangup pour une obscure "cause 100"
Le fameux message d'erreur lorsque j'essaye d'appeler le 1013 de FT :
-- Executing Dial("SIP/400-cd94", "Zap/g1/1013")
-- Requested transfer capability: 0x00 - SPEECH
-- Called g1/1013
-- Channel 0/1, span 1 got hangup, cause 100
-- Channel 0/1, span 1 received AOC-E charging 0 units
-- Hungup 'Zap/1-1'
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing Hangup("SIP/400-cd94", "")
== Spawn extension (default, 1013, 2) exited non-zero on 'SIP/400-cd94'
Si vous avez un peu de lumière pour éclairer ma lanterne, je suis preneur !
Merci d'avance,
Quelques extraits de mes fichiers de conf :
zaptel.conf
-------------
loadzone=fr
defaultzone=fr
# qozap span definitions
# most of the values should be bogus because we are not really zaptel
span=1,1,3,ccs,ami
span=2,0,3,ccs,ami
span=3,0,3,ccs,ami
span=4,0,3,ccs,ami
span=5,1,3,ccs,ami
span=6,0,3,ccs,ami
span=7,0,3,ccs,ami
span=8,0,3,ccs,ami
bchan=1,2
dchan=3
bchan=4,5
dchan=6
bchan=7,8
dchan=9
bchan=10,11
dchan=12
bchan=13,14
dchan=15
bchan=16,17
dchan=18
bchan=19,20
dchan=21
bchan=22,23
dchan=24
zapata.conf
-------------
[channels]
switchtype = euroisdn
; p2mp TE mode (for connecting ISDN lines in
; point-to-multipoint mode)
;signalling = bri_cpe_ptmp
pridialplan = dynamic
prilocaldialplan = local
nationalprefix = 0
internationalprefix = 00
usecallingpres = yes
echocancel = yes
echocancelwhenbridged = yes
echotraining = 100
signalling = bri_cpe
context=isdn-incoming
group = 1
; S/T port 1,2,7,8
channel => 1-2
channel => 4-5
;channel => 19-20
channel => 22-23
J'ai le même problème avec la dernière version d'Asterisk.
Vous pouvez essayer avec la version 0.2q de bristuff, cela devrait marcher.
L'inconvénient c'est que c'est une vielle version de Asterisk.
Avez-vous essayé de contacter junghanns.net pour ce problème, car je leur ai décrit par mail et il me disent que ça n'arrive pas avec leur carte et moi j'utilise des cartes 1 port génériques.
Essayez de relire quelques messages précendent, car nous avons déja discuté de cela récement.
J'ai également posté sur la liste asterisk-user et un utilisateur espagnol à le même problème en espagne avec une Quad-BRI
Hello,
Si tes accès de base sont bien en ETSI (euronumeri+), mais ce qui est important c'est l'ETSI et que tu positionnes dans Zapata.conf, la variable signalling = bri_cpe_ptmp. J'ai vérifier ta configuration, tout devrait fonctionner corretement.
J'ai plusieurs sites avec des accès récents et d'autres ancien au sens TMR et cela fonctionne parfaitement avec présentation de l'identification de l'appelant. D'ailleurs, aujourd'hui je n'installe que des cartes Quad ou OctoBRI parce que plusieurs cartes mono engendrent des problèmes de latence sur le bus PCI.
A+
Hello à tous,
Merci jean007 et ol555 pour ces petites infos.
J'ai bien remis la variable signalling = bri_cpe_ptmp dans mon zapata.conf et je continue à chercher assiduement l'origine de mon problème toujours pas résolu.
J'ai activé le debug sur le span 1 de ma carte. Voilà ce qua ça donne lorsque j'essaye d'appeler le 1013 de France Telecom. Au début tout semble bien se passer, puis ensuite j'ai cette erreur de protocole bizarre... Et pourtant, j'arrive bien à recevoir les appels...
Quelqu'un aurait une petite idée ou un conseil..? Merci d'avance,
Seb.
-- Executing Dial("SIP/400-c8dc", "Zap/1/1013")
1 -- Making new call for cr 137
-- Requested transfer capability: 0x00 - SPEECH
1 > Protocol Discriminator: Q.931 (8) len=26
1 > Call Ref: len= 1 (reference 9/0x9) (Originator)
1 > Message type: SETUP (5)
1 > [1 041 031 801 901 a31 ]
1 > Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0)
1 > Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
1 > Ext: 1 User information layer 1: A-Law (35)
1 > [1 181 011 811 ]
1 > Channel ID (len= 3) [ Ext: 1 IntID: Implicit, Other Spare: 0, Preferred Dchan: 0
1 > ChanSel: B1 channel
1 ]
1 > [1 6c1 051 411 801 341 301 301 ]
1 > Calling Number (len= 7) [ Ext: 0 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
1 > Presentation: Presentation permitted, user number not screened (0) '400' ]
1 > [1 701 051 c11 311 301 311 331 ]
1 > Called Number (len= 7) [ Ext: 1 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '1013' ]
-- Called 1/1013
1 < Protocol Discriminator: Q.931 (8) len=8
1 < Call Ref: len= 1 (reference 137/0x89) (Terminator)
1 < Message type: RELEASE COMPLETE (90)
1 < [1 081 021 871 e41 ]
1 < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: International network (7)
1 < Ext: 1 Cause: Unknown (100), class = Protocol Error (6) ]
1 -- Processing IE 8 (cs0, Cause)
-- Channel 0/1, span 1 got hangup, cause 100
1 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
1 NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
-- Hungup 'Zap/1-1'
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing Hangup("SIP/400-c8dc", "")
== Spawn extension (default, 1013, 2) exited non-zero on 'SIP/400-c8dc'
1 received TEI check request for TEI = 127
Je cherche une réponse à cela depuis des semaines,
j'ai posté sur la liste asterisk-users, j'ai contacté junghanns.net, mais pas de réponse pour l'instant.
Le problème se pose aussi en espagne car quelqu'un m'a contacté après mon message sur la liste asterisk-users.
Pour le moment je sèche un peu, et c'est un peu génant pour mes futures install.
Je ne sais plus trop où chercher, mais en tout cas cela fonctionne bien à mon bureau, mais pas chez la pluspart de mes clients. Je ne sais pas ce qui à changé entre la 0.2 et la 0.3 qui fasse planter sur les lignes FT.
Hello,
Merci pour ta réponse.. Donc tu sous-entend qu'avec la version 0.2 ca fonctionne bien..? As-tu fait des tests avec mISDN ou vISDN ?
Je retente une compil d'Asterisk et de mon kernel avec mISDN, je te tiendrais au courant...
A+,
Seb.
Avec la 0.2 pas de soucis pour la stabilité de la connexion numéris.
Par contre j'ai des problèmes en mode NT pour la connexion de PABX Alcatel (90% des PABX chez mes clients) et cela semble marcher avec la version 0.3.
Et puis il y a plein de nouvelles fonctions et de correction de bugs depuis la version 1.0.10 de Asterisk.
Je vais essayer de poster sur asterisk-dev pour voir.
Sinon je vais essayer de regarder ce qui à changé dans le code du driver.
J'utilise aussi le patch de http://zaphfc.florz.dyndns.org/ sinon les cartes 1 port sont inutilisables.
Je vais essayer de le contacter aussi.
Le problème n'as pas l'air spécifique à la france, mais c'est cela semble venir du comportement particulier du canal D sur certains équipements RNIS.
J'utilise le kernel 2.4.21 dans la pluspart des cas.
Oui, moi aussi ça m'embête de revenir à la version 1.0.10 et de passer à côté des améliorations apportées depuis... :-(
J'ai écrit à junghanns avec la description complète de mon problème.
Je te tiens au courant,
Finalement, je pense que je vais downgrader à la version 1.0.10...
Sinon, je suis toujours en dernière version de kernel, donc actuellement en 2.6.15.
A bientôt
tu à écrit à junghanns sur quelle adresse? j'ai essayé de les contacter via le site web, mais je n'ai eu qu'un commercial qui me dit que tout marche!
J'ai essayé de poster sur asterisk-dev, mais je me suis fait un peu jeté car bristuff ne fait pas parti de asterisk.
J'ai tout simplement écrit à contact@junghanns.net
En espérant avoir une réponse...
:?
Ok merci,
j'ai envoyé un mail bien détaillé.
on vas voir si ils repondent.
Sinon je vais essayer chan_misdn pour voir ce que cela donne.
Je viens de tout recompiler en bristuff-0.2 avec un asterisk en 1.0.10 et j'ai exactement le même problème de protocol unknow !!!
On dirait que la vérité est ailleurs..... :cry:
généralement ça ça ne marche pas en mode TE (en tous cas sur toutes mes lignes):
signalling = bri_cpe
essaye avec signalling = bri_cpe_ptmp
vu sur asterisk-users:
[Asterisk-Users] ISDN Protocol Unknom Error with Junghanns OctoBRI
------coupé------
> loadzone=fr
> defaultzone=fr
> # qozap span definitions
> # most of the values should be bogus because we are not really zaptel
> span=1,1,3,ccs,ami
> span=2,0,3,ccs,ami
> span=3,0,3,ccs,ami
> span=4,0,3,ccs,ami
> span=5,1,3,ccs,ami
> span=6,0,3,ccs,ami
> span=7,0,3,ccs,ami
> span=8,0,3,ccs,ami
>
I was going mad with a Quadbri until I changed ccs,ami to ccs,hdb3 and
it's been running 6 months now.
je vais essayer ça ce soir après les heures d'ouvertures de mes sites pour essayer ce que cela donne.
Hello,
Tu ne m'as pas répondu quand à la configuration France Telecom de tes lignes. Sont-elles en ETSI Numeris+. Ceci est très important et correspond au symptome décrit.
A+
Pour info, on peut joindre le support technique Junghanns en IAX.
A mettre par exemple dans votre extensions.conf :
; Junghanns hotline
exten => 911,1,Dial(IAX2/guest@pbx.jnetdns.de)
exten => 911,2,Hangup
J'ai le même problème en Euronuméris + et pas + mais ça fonctionne correctement pendant quelques minutes en pas +
J'ai eu Eikonex qui vend la carte en france, et qui me conseille de mettre pridialplan=unknown et prilocaldialplan=unknown dans zapata.conf
je teste ça tout à l'heure
Ronhanson
27/03/2006, 13h07
J'ai presque exactement le même problème avec un PRI et une carte TE205P Digium... J'ai meme posté a ce sujet ce matin, et je suis toujours dans le flou.
Je pense passer de Euronumeris+(VN6) vers Euronumeris(ETSI) pour voir si ca regle le probleme. En attendant, je fais des test avec FT sur ma ligne. Il semble qu'ils pensent qu'elle est en dérengement alors qu'en mode "debug intense", je vois bien passer les trames de supervision que j'envoie, à laquelle je réponds ou autre...
A suivre... en esperant que ce probleme soit reglé assez vite.
Bon courage.
Ronan
Ronhanson
27/03/2006, 13h59
Pour info, apres avoir mis pridialplan=unknown et prilocaldialplan=unknown dans zapata.conf, j'ai deplacé l'erreur mais c'est déjà mieux :
< Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 2/0x2) (Terminator)
< Message type: RELEASE COMPLETE (90)
< [08 02 87 bb]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: International network (7)
< Ext: 1 Cause: Unknown (59), class = Service or Option not Available (3) ]
Sending Receiver Ready (1)
J'ai donc droit a une erreur a peu pres inconnue sur le net, ou en tout cas sans solution toute donnée.
Bon courage.
Ronan
Ce qui me rassure un peu c'est que le pb existe aussi avec une carte Digium.
Ca vas me permettre de reposter sur asterisk-dev sans me faire jetter pour cause de produit non-asterisk.
je vais faire quelques test demain, dès que j'aurais recu mes nouvelles cartes.
Juste pour info, mes seules lignes ou cela fonctionne avec asterisk 1.2, ce sont des lignes euronuméris pas +
Ronhanson
28/03/2006, 14h02
J'ai fait la demande aupres de FT pour passer en Euronumeris pas +, car c'est la norme ETSI (EuroISDN) et pas VN6 propriétaire FT. Demande payante bien evidemment...
Peux tu me confirmer qu'avec une ligne Euronumeris tu n'as pas de problèmes avec tes BRI/PRI?
Merci d'avance, et bon courage.
Ronan
En tous cas les deux groupements de lignes qui fonctionnent avec le 1.2.4 sont en Euronuméris.
Ceux en Euronuméris+ fonctionnent avec asterisk 1.0.10 mais pas du tout avec le 1.2.4
j'ai déja demandé ce changement mais il ne me semble pas avoir payé. c'est bizarre.
Mais j'ai des lignes en Euronuméris qui déconnent, elle fonctionnent une heure à peu près et ensuite elle se désactivent.
Je vais tester ce soir pridialplan=unknown et prilocaldialplan=unknown comme conseillé par Eikonex dans ce cas.
J'ai installé hier un nouveau PBX avec une QuadBRI, deux To EuroISDN (pas +) sur FT et un PABX alcatel 4200 connecté par deux To en mode NT.
La version utilisée est: bristuff-0.3.0-PRE-1k.tar.gz
J'ai mis les paramètres pridialplan=unknown et prilocaldialplan=unknown et miracle!!! ça marche.
En fait les canaux FT se désactivent très rapidement, mais se réactivent en cas d'appel entrant et d'appel sortant.
ça ressemble à une sorte d'économie d'énergie.
Au bout d'une demi-journée de fonctionnement normal (entreprise ouverte et avec une forte activitée téléphonique), tout semble fonctionner normalement.
Je vais tester ce weekend sur d'autres sites.
Pour info le site se situe à Lyon.
Bravo ol555 !
Je vois que tu avances bien sur les problèmes !
Cela semble confirmer qu'il faut absolument être en EuroISDN et pas en EuroISDN+ !!
Quelques nouvelles de mon install OctoBRI....
Pour l'instant, j'ai abandonné zaptel et je suis passé à mISDN
Ce week-end, ca fonctionnait nickel. Bon, j'ai tout de même remarqué que mISDNStackd lançait de nombreux process et augmentait pas mal le load average de la machine (environ 0.50 sans appel téléphonique sur un P4 3,2Ghz avec 512Mo RAM sous Gentoo Linux - OctoBRI avec 3 TE et 3 NT)
Les tests étaient concluants :
- Possible de passer des appels à l'extérieur
- Possible d'en recevoir
- Toutes les fonctionnalités d'Asterisk disponibles
Bref nickel !
Aujourd'hui, système chargé, c'était beaucoup moins nickel !!
Je vais d'ailleurs ouvrir un nouveau topic pour les problèmes rencontrés sur mISDN.
- Système très chargé (entre 0.50 et 1.30)
- Canaux FT qui aussi se désactivement très rapidement après un appel mais ne se réactivent pas forcément en cas d'appel entrant ou sortant. De ce fait, au bout d'un certain temps, toutes mes connexions en TE passe en DOWN et il est impossible de passer un appel. Il en est de même pour mes connexions en NT mais ça arrive moins vite.
En tapant la commande misdn port up # dans le CLI, les lignes repassent en UP et cela résoud le problème temporairement...
- A l'établissement d'une communication téléphonique, il arrive qu'un des correspondants n'entende qu'un bruit parasite (le même que lorsque l'on règle son téléviseur sur un canal où il n'y a rien), alors que l'autre n'entend rien, hormis la voix du premier bien sur !
Correspondant 1 >>>>> PARASITES >>>>> Correspondant 2
Correspondant 1 <<<<<<< OK <<<<<<<<< Correspondant 2
L'echocancel n'est pas activé.. je ne vois rien de particulier dans les logs où plutôt je ne sais pas pour l'instant où chercher..... A votre bon coeur si vous avez un conseil à me donner...
La suite au prochain épisode...
Sol-R
Ronhanson
05/04/2006, 09h15
Et bien ecoutez, j'ai reglé ce problème simplement pour ma part.
En fait, il semble que le VN6(Euronumeris+) soit compatible avec ETSI(Euronumeris). Donc, cela ne devrait pas poser de problèmes.
Je préconise cependant de passer la ligne en Euronumeris pas +, ca sera toujours mieux.
Cependant, il y a 2 choses qui ont reglé mon problème :
dans zapata.conf :
pridialplan = unknown
prilocaldialplan = unknown
Sans cela tu auras une erreur "cause unknown / protocol error".
Après avoir reglé cela, tu auras peut-être, si cela n'a pas resolu ton problème, un "service or option not available" à la place. Et là, la réponse est simple :
#Appeller France-Télécoms;
#Harceler France-Télécoms;
Les appeller parce qu'ils n'ont pas terminé d'ouvrir ta ligne, ils attendent que tu leurs confirme l'ouverture et les SDA si tu en as! Maintenant, il faut trouver le bon service et passer comme moi une bonne semaine à les harceler. Voilà, je crois maintenant avoir compris la premiere des rêgles lorsque l'on fait de la téléphonie : mettre en cause FT dès que ca bug.
Ils sont compétents, souvent sympatiques, mais leur gros problème, c'est la multiplicité de services différents intervenant pour une simple installation. Ils ont une communication à faire peur, et une organisation pourrave, du coup ils se rejetent sans cesse la faute entre services.
Bon courage,
j'espere que cela resoudra ton problème.
Cordialement,
Ronan
Salut Ronhanson !!
Et bien ton petit post me redonne espoir et le laisse penser qu'on peut y arriver... Je vais donc me mettre à harceler France Telecom...
Je vous tiens au courant,
A+,
Sol-R
Hello Ronhanson !!
Encore une petite question.. Tu as utilisé quelle version d'asterisk, bristuff et zaptel pour aboutir à une installation qui fonctionne..?
Merci d'avance,
A+,
Sol-R
Ronhanson
06/04/2006, 10h33
j'ai un Asterisk@home 2.6 et j'ai recompilé asterisk avec la derniere version de Zaptel, et la derniere de libpri. Ca marche très bien et aucun souci de compatibilité avec ces modifs.
Bon courage, n'hésite pas à envoyer les logs ISDN de ton serveur lors d'un appel. Meme un petit log "pri intense debug" sera utile.
Si tu veux m'appeller et qu'on en discute 2 secondes, envoie moi un message perso.
Bon courage,
Ronan
Il semble que le dernier problème qui me reste soit dû au patch de http://zaphfc.florz.dyndns.org/ qui sert à supprimer les pb d'irq sur les cartes 1 port.
Sans ce patch les appels passent bien (sortant et entrant). Le souci c'est que le son est pourris, car c'est ce que corrige ce patch.
Le problème n'est pas présent avec les cartes junghanns, car le patch est nécessaire uniquement pour les cartes 1 port qui utilisent le driver ZAPHFC.
Donc le fameux problème est que je peut passer 1 appel et que ensuite le port se désactive (c'est normal donc finalement) mais il ne se réactive pas.
J'ai essayé de contacter l'auteur du patch mais je n'ais pas eu de réponse.
Je vais re-essayer ce week-end.
Pour info, j'ai testé misdn avec une carte 1 port sur 2 sites, mais cela plante carrement la machine de temps en temps. Ca n'a pas l'air très au point pour l'instant.
Comme le driver bristuff fonctionne parfaitement avec les cartes Quad et OctoBri, j'ai entrepris de chercher les différences entre les drivers qozap et zaphfc. La plus grosse différence, c'est que zaphfc n'as pas évolué depuis des mois. Le problème que je rencontre (le canal ne sort pas de la veille activé par l'opérateur lors d'un appel sortant) semble géré dans qozap.
J'ai essayé d'intégrer les modifications dans le driver zaphfc sans grand succès pour l'instant.
je vais peut être essayer d'adapter qozap pour les cartes 1 canal vu qu'il n'y a quasiment pas de differences entre les 3 circuits, a apart le nombre de canaux.
vBulletin v.3.8.0, Copyright © 2000-2010, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org