Onderwerp: asterisk & linksys prob

Hallo,

Sinds enkele weken draait er een Asterisk/freepbx met een 7-tal linksys spa962 toestellen.

Wij hebben echter problemen dat ongeveer 10%-20% van de gesprekken niet tot stand gebracht kunnen worden (telefoon gaat over, maar geen audio hoorbaar langs beide kanten).
Tweede probleem is dat de asterisk soms eens vastloopt (kan echter gewoon een slecht stukje ram zijn, wat ik nu aan het testen ben).

Ben zelf absoluut geen expert en de installateur kan er zelf niet meer aan uit.

Zijn er bepaalde dingen die ik zelf kan nagaan?


Asterisk staat op een Dell server met een Digium 4port ISDN kaart.
De installateur heeft de standaard howto van Digium gevolgd en de ISDNstack van hun gedownload. Hij verdenkt dat de ISDNstack een probleem geeft, daar de server vast loopt en hij een rare isdnstack boodschap ziet.

Kan iemand me op weg helpen ... wat kan ik alvast nakijken.

misdn-init.conf
card=1,0x4
te_ptp=1,2
poll=128
dsp_poll=128
dsp_options=0
dtmfthreshold=100
debug=0

te_ptp staat in de howto echter ingesteld op 3,4
ook zeggen ze "nt_ptp=1,2" in de config te zetten, die bij ons echter geheel ontbreekt.

NT en TE is het type aansluiting (of er ISND lijnen of ISDN telefoons aanhangen). De nummertjes staan voor de poorten die je gebruikt op je quad BRI kaart.

Dus te_ptp is goed als je een isdn lijn op poort 1 en 2 hebt.



EDIT:
Draai je ergens NAT in je setup of zit alles op hetzelfde LAN?

(Ken wel niet echt iets van freepbx toestanden daar wij gewoon een plain asterisk doos bij de klant neerzetten. Geraak je bij deze dingen op de asterisk CLI?)

Oorspronkelijk geplaatst door luser

NT en TE is het type aansluiting (of er ISND lijnen of ISDN telefoons aanhangen). De nummertjes staan voor de poorten die je gebruikt op je quad BRI kaart.

Dus te_ptp is goed als je een isdn lijn op poort 1 en 2 hebt.

ok, dat lijkt me dan inderdaad wel in orde. Er zijn 2 isdn lijnen op poort 1 en 2

EDIT:
Draai je ergens NAT in je setup of zit alles op hetzelfde LAN?

(Ken wel niet echt iets van freepbx toestanden daar wij gewoon een plain asterisk doos bij de klant neerzetten. Geraak je bij deze dingen op de asterisk CLI?)

Asterisk server en toestellen staan binnen hetzelfde LAN. CLI is bereikbaar ... zo heb ik al enkele dingen zelf aangepast (caller id etc...), maar de echte core config is mij grotendeels onbekend.

In de misdn-init.conf staan er ook enkele "options" in comment ... kan het daar iets mee te maken hebben?

Normaal heb je in de /etc/asterisk/misdn.conf een optie:
te_choose_channel, zet deze eens op yes.

Helpt wel eens bij vage problemen. Welke telco gebruik je?

Oorspronkelijk geplaatst door luser

Normaal heb je in de /etc/asterisk/misdn.conf een optie:
te_choose_channel, zet deze eens op yes.

Helpt wel eens bij vage problemen. Welke telco gebruik je?

K, heb het aangepast in de config. Kan ik dit laden zonder reboot?

Momenteel gaat alles via Belgacom ... VoipBuster is ook ingesteld, maar wordt in praktijk niet gebruikt wegens de probs.

Doe op de cli (asterisk -r): misdn reload

EDIT:

Je krijgt de probs ook richting voipbuster? Dit gaat niet via mISDN dus zit je probleem ergens anders

-- Called g:first_extern/0486738852/:s:e128
-- mISDN/1-u17 is proceeding passing it to SIP/23-08adf0b0
-- mISDN/1-u17 is ringing
-- SIP/30-08ad9b70 answered mISDN/1-1
-- mISDN/1-u17 answered SIP/23-08adf0b0
== Spawn extension (macro-dialout-trunk, s, 30) exited non-zero on 'SIP/23-08adf0b0' in macro 'dialout-trunk'
== Spawn extension (macro-dialout-trunk, s, 30) exited non-zero on 'SIP/23-08adf0b0'
-- Executing Macro("SIP/23-08adf0b0", "hangupcall") in new stack
-- Executing ResetCDR("SIP/23-08adf0b0", "w") in new stack
-- Executing NoCDR("SIP/23-08adf0b0", "") in new stack
-- Executing GotoIf("SIP/23-08adf0b0", "1?skiprg") in new stack
-- Goto (macro-hangupcall,s,6)
-- Executing GotoIf("SIP/23-08adf0b0", "1?skipblkvm") in new stack
-- Goto (macro-hangupcall,s,9)
-- Executing GotoIf("SIP/23-08adf0b0", "1?theend") in new stack
-- Goto (macro-hangupcall,s,11)
-- Executing Hangup("SIP/23-08adf0b0", "") in new stack
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/23-08adf0b0' in macro 'hangupcall'
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/23-08adf0b0'


dan kan ik bellen, maar van zodra de persoon opneemt valt de lijn weg.

Loopt iets fout in de macro denkik. Maak best even een dialout extensie die direkt de misdn aanroept.

Iets in formaat van:
[sip-to-isdn-out]
exten => _0.,1,Dial(mISDN/g:first_extern/${EXTEN:1})
exten => _0.,2,Hangup()

Dan de context bij je uitgaande sip context includen.
Vanaf dan kan je buitenbellen met prefix 0.

wat vraag jij om een config eens na te kijken?

Dit

Wij hebben echter problemen dat ongeveer 10%-20% van de gesprekken niet tot stand gebracht kunnen worden (telefoon gaat over, maar geen audio hoorbaar langs beide kanten).

wordt in 90% van de gevallen veroorzaakt door NAT. Een Firewall op de linux doos die niet goed ingesteld staat (bv IP tables die de de poorten waarover de spraak plaatst vindt niet goed door laten), of een modem (Thomson/Alcatel) waarbij NAT stiekem toch niet werkt zoals het zou moeten.

Kijk voor de zekerheid je IP tables even na (aan een modem zal het niet liggen omdat de gesprekken via de ISDN kaart binnen komen).

Geldt dit trouwens voor uitgaande en inkomende gesprekken?

Oorspronkelijk geplaatst door Mark Vletter

Dit wordt in 90% van de gevallen veroorzaakt door NAT. Een Firewall op de linux doos die niet goed ingesteld staat (IP tables laten de poorten waarover de spraak plaatst vindt niet goed door), of een modem (Thomson/Alcatel) waarbij NAT stiekem toch niet werkt zoals het zou moeten.

Kijk voor de zekerheid je IP tables even na (aan een modem zal het niet liggen omdat de gesprekken via de ISDN kaart binnen komen).

Geldt dit trouwens voor uitgaande en inkomende gesprekken?

voor zover ik weet voor inkomende gesprekken ... maar daarvoor moet ik men collega's eens raadplegen.

Dan is de kans dat het een nat probleem is nog groter... Kijk eens in je IP tables wat er gebeurd met de poorten 10000 t/m 10500.

Oorspronkelijk geplaatst door TomB

voor zover ik weet voor inkomende gesprekken ... maar daarvoor moet ik men collega's eens raadplegen.

In één van je posts vertel je dat voipbuster momenteel niet gebruikt wordt, dus je hebt dit probleem ook voor gesprekken die toekomen via je ISDN lijnen?

Oorspronkelijk geplaatst door luser

In één van je posts vertel je dat voipbuster momenteel niet gebruikt wordt, dus je hebt dit probleem ook voor gesprekken die toekomen via je ISDN lijnen?

VoipBuster gebruiken we momenteel niet, maar gewoon omdat we ons eerst willen concentreren op de problemen via ISDN.
Die werkt wel, maar nog niet genoeg getest om te zien of we via dat kanaal dezelfde probs hebben.


edit: heb net mijn collega's effe gesproken, en zij hebben het probleem ook al ondervonden als zij zelf iemand bellen (uitgaand dus).

Kunnen ze zonder problemen naar elkaar toe bellen?