Analog/ISDN über CAPI / Probleme / Echo

[dynamic]

@CTU
Ist auf dem 7940 und 7970 der gleiche Codec eingestellt ?
Falls nicht, versuch beide mal auf den gleichen Codec zu setzen.

Je nach genutztem Codec wird der Rechenaufwand für die FBF größer.
Versuch es mal mit G711alaw, falls dies nicht der fall sein sollte.

 

[CTU]

Hi,
danke für die Antwort !

1.) Wo kann bei den Cisco-Telefonen nachschauen, welchen Codec sie nutzen ? ( Kenne den Menüeintrag gar nicht )

2.) Wo kann man einstellen, welcher Codec vom Asterisk verwendet werden soll ?


Danke,
mfg CTU

 

[dynamic]

@CTU
Setze testweise in modules.conf alle Codecs ausser codec_alaw mal of "noload".

 

[CTU]

Hi,
also bei mir siehte die modules.conf so aus:

preload =>res_features.so
preload =>codec_alaw.so
;noload => res_musiconhold.so
;

Müsste das nicht heißen, dass nur a_law zugelassen ist ? Oder ist das so zu verstehen, dass ich zusätzlich alle anderen codecs auf noload setzen muss, auch die, die nicht bei preload aufgeführt sind ?

Danke,
mfg CTU

 

[spblinux]

Oder ist das so zu verstehen, dass ich zusätzlich alle anderen codecs auf noload setzen muss, auch die, die nicht bei preload aufgeführt sind ?

genau, alle auf noload (wegen autoload Funktion)

spblinux

 

[dynamic]

@CTU
kannst zur Überprüfung via "show translation" ( bzw. "core show translation" ) am CLI Prompt auch die Codecs sowie die "Translation times" anzeigen lassen

 

[CTU]

Hi,
also nochmal zu meinem Problem:

Ich habe die Asterisk-Version, die man unter fbox.net bekommt.

Ich habe unter show translation das hier bekommen:

g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 speex ilbc
g723 - - - - - - - - - - -
gsm - - - - - - - - - - -
ulaw - - - 1 - - 11 - - - -
alaw - - 1 - - - 10 - - - -
g726 - - - - - - - - - - -
adpcm - - - - - - - - - - -
slin - - 2 1 - - - - - - -
lpc10 - - - - - - - - - - -
g729 - - - - - - - - - - -
speex - - - - - - - - - - -
ilbc - - - - - - - - - - -

und habe nur die codecs alaw und a_mu geladen.

Ich bekomme immer noch sämtliche Szenarien:

1. Gute Sprachübertragung in beide Richtungen
2. Gute Sprachübertragung nur in eine Richtung, in die andere Richtung gar keine
3.) In gar keine Richtung Sprachübertragung

Und all dies passiert sproadisch, ohne irgendwelche Configs geändert zu haben.
Außerdem habe ich, um ganz sicher zu gehen, dass es nicht an CAPI -> SCCP liegt, auch mal ein SIP-geflashtes 7940 getestet und das gleiche Ergebnis bekommen. Bei CAPI -> SIP also auch keine Veränderung.

Daher noch eine letzte Vermutung: Ich habe irgendwo gelesen, dass bestimmte chan_capi-Versionen mit bestimmten Linux-Kernels nicht zusammenarbeiten. Kann mir jemand diesbezüglich was sagen, wie das bei der FBF 7170 aussieht ?

Danke,
mfg CTU

 

[dynamic]

@php
Jetzt müsste alles wieder ganz normal laufen.

@CTU
Ganz erklären kann ich mir das leider auch nicht.
Man könnte jetzt noch ein noch paar andere Tests machen ... wie z.B. von IAX <-> SIP, IAX<->IAX oder SIP <-> SIP, um zu sehen ob das Problem tatsächlich mit der CAPI Schnittstelle zusammenhängt.

Falls Du noch nicht auf * v1.4.2 bist, wäre evtl. auch einen Versuch Wert einfach auf v1.4.2 upzugraden ( siehe dazu hier ). In dieser Version ist CAPI v1.0.1 enthalten.

Aus Deinem Posting ist auch ersichtlich, daß bei Dir der "ulaw" codec geladen wird. Diesen kannst Du rausnehmen, da in EUR Gefilden "alaw" genutzt wird.

Gruß
dynamic

 

[CTU]

Hi,
also das mit dem neuen Asterisk werde ich testen.
Übrigens ist das nicht ulaw, sondern alar, nur man erkennt es sehr schlecht, da die Zeilen etwas verrutscht sind ;-)

Und, ja das hängt mit CAPI zusammen, da intern SCCP kein Problem ist, SIP -> SCCP auch nicht, da 1&1, Sipgate und AOL Telefonate ohne Probleme gehen.

Also, ich werde weiter berichten Aber solange es noch Tests gibt, die das Problem lösen könnten, bin ich noch zuversichtlich

mfg,
CTU

 

[CTU]

Ich hab wohl ein 2.4-er Kernel, weil der sagt mir, dass ein 2.6er notwendig ist und bricht die installation ab, daher gehe ich mal davon aus, dass ich keine 2.6er habe. Kann ich das ändern, bzw. wie hast du das gemacht ?


mfg,
CTU

 

[dynamic]

@CTU
Einfach die FW des 7170 upgraden ... die aktuellste Version hat 'nen 2.6'er Kernel.

Wegen dem Codec ... bei Dir sind definitiv "alaw" als auch "ulaw" geladen!

ulaw - - - 1 - - 11 - - - -
alaw - - 1 - - - 10 - - - -

 

[CTU]

Hi,
hmm das ist komisch, den unter den modules kommt als codec nur noch alaw vor und kein ulaw. Wie erklärt man sich den Eintrag in der Tabelle von sho translation ? komisch ....

aber die Installation des 1.2.14er geht jetzt ;-) das Update auf 29.04.29 hats gebracht. Welche Änderungen hat der neue Asterisk eigentlich so mit sich gebracht ?

danke,
mfg CTU

 

[dynamic]

@CTU
Hast DU jetzt die 1.2.18 installiert oder die 1.4.2 ?
Die Installation des * v1.4.2 erfolgt via cfg_asterisk14 ( nicht via cfg_asterisk ) .
In v1.4.2 ist die aktuellste CAPI v1.0.1 enthalten ... in der v1.2.18 befindet sich noch die Version 0.7.x .

 

[CTU]

@dynamic: Ja, ich habe cfg_asterisk14 installiert (Habe mich oben vertippt^^):
So, jetzt habe ich nochmal einen Test gemacht, vll bringt der uns ja weiter:

Undzwar habe ich ein Cisco 7940 genommen ( angemeldet aus Asterisk "A", auf einem vServer ) und eben mein 7970 ( angemeldet auf Asterisk "B", auf der FBF 7170 ). Ich habe über das 7940 dann per Sipgate das 7970 angerufen. Interessanterweise liefern die RTP-Debugs unterschiedliches:

RTP-Debug auf Asterisk vServer:

Got RTP packet from 172.158.199.187:22080 (type 8, seq 4160, ts 714368, len 160)
Sent RTP packet to 217.10.68.67:18272 (type 8, seq 18182, ts 108800, len 160)
Got RTP packet from 172.158.199.187:22080 (type 8, seq 4161, ts 714528, len 160)
Sent RTP packet to 217.10.68.67:18272 (type 8, seq 18183, ts 108960, len 160)
Got RTP packet from 172.158.199.187:22080 (type 8, seq 4162, ts 714688, len 160)
Sent RTP packet to 217.10.68.67:18272 (type 8, seq 18184, ts 109120, len 160)
Got RTP packet from 172.158.199.187:22080 (type 8, seq 4163, ts 714848, len 160)
Sent RTP packet to 217.10.68.67:18272 (type 8, seq 18185, ts 109280, len 160)
Got RTP packet from 172.158.199.187:22080 (type 8, seq 4164, ts 715008, len 160)
Sent RTP packet to 217.10.68.67:18272 (type 8, seq 18186, ts 109440, len 160)
Got RTP packet from 172.158.199.187:22080 (type 8, seq 4165, ts 715168, len 160)
Sent RTP packet to 217.10.68.67:18272 (type 8, seq 18187, ts 109600, len 160)


RTP-Debug auf Asterisk FBF 7170:

Got RTP packet from 192.168.178.21:19458 (type 08, seq 002143, ts 812336, len 000160)
Got RTP packet from 192.168.178.21:19458 (type 08, seq 002144, ts 812496, len 000160)
Sent RTP packet to 192.168.178.21:19458 (type 08, seq 000346, ts 042080, len 000160)
Sent RTP packet to 192.168.178.21:19458 (type 08, seq 000347, ts 042240, len 000160)
Got RTP packet from 192.168.178.21:19458 (type 08, seq 002145, ts 812656, len 000160)
Got RTP packet from 192.168.178.21:19458 (type 08, seq 002146, ts 812816, len 000160)
Sent RTP packet to 192.168.178.21:19458 (type 08, seq 000348, ts 042400, len 000160)
Sent RTP packet to 192.168.178.21:19458 (type 08, seq 000349, ts 042560, len 000160)
Got RTP packet from 192.168.178.21:19458 (type 08, seq 002147, ts 812976, len 000160)


Was mir auffällt ist, dass bei beim Asterisk "A" unter "got packet from" und "sent packet to" unterschiedliche IPs stehen, was auch einleuchtet.
Beim Debug vom Asterisk "B" ist da immer die gleiche IP, nämlich die meines 7970.

Kann jemand daraus etwas interpretieren ?
Btw: Das Problem mit der Sprachübertragung besteht momentan trotz 1.4.2 immer noch :-(

danke,
mfg CTU

 

[CTU]

Hallo,
oder fragen wir mal anders:

Wie wird die Sprache bei CAPI übertragen ? Ja nicht über Codecs, soweit ich weiß. Spielen vll die RTP-Ports eine Rolle ? Müssen welche geforwardet werden ?
Muss man dann auf das jeweilie Telefon oder auf den gesamten Asterisk forwarden ? ( Ich frage deshalb, weil eine Protfreigabe auf 192.168.178.1 nicht möglich ist )

Btw.: Nach weiteren ausgiebigen Tests ist es so, dass die Qualität der Sprachübertragung vom Anrufenden richtung meinem Asterisk immer herovrragend ist, von mir richtung Anrufenden aber nie eine Audio-Verbindung besteht.


mfg,
CTU

 

[stefanwillmerot]

ISDN und damit auch CAPI benutzen hierzulande immer ALAW als Codec. Die Box dürfte die analoge Telefonie also irgendwie digitalisieren und in alaw codieren.

 

[CTU]

Ok danke !
Dann hatte ich leider eine Fehlinformation bezüglich CAPI und den Cpdecs.
Aber bringt mich das irgendwie weiter ? Weil irgendwie lädt sich trotz nolad auch der ulaw_codec. Und mir wurde hier geraten den erstmal auf noload zu setzen. Könnte das Probleme bezüglich CAPI beheben ?
Muss man für Codecs bestimmte Ports freigeben oder sind das eben diese RTP-Ports ?


Danke,
mfg CTU

 

[spblinux]

@CTU:
a) verstehe ich richtig: die ganzen Schwierigkeiten sind bei analog eingehenden Telefonaten?

b) wenn ja: wie sieht es mit ausgehenden analogen Telefonaten aus? Gehen die denn zuverlässig?

c) "abheben direkt nach dem ersten klingeln geht nie": braucht es immediate=yes in der capi.conf wirklich? (auch nachdem in extensions.conf _X. durch s ersetzt wurde, oder geht s zusammen mit immediate=no auch?)

d) wenn analog ausgehend funktioniert, wäre ein denkbares workaround die analog eingehenden Rufe per fritzbox Rufumleitung (sofort: Festnetz -> am fritzbox asterisk angemeldete Internetrufnummer) entgegenzunehmen.

edit:
e) Die RTP-Ports legen bei SIP bzw. SCCP fest unter welcher Portnummer die Audiodaten per udp übertragen werden. - Wenn die Verbindungprobleme nicht auf der Teilstrecke cisco - * liegen, dann bringt es auch wenig den rtp Datenstrom zu untersuchen.

Aber um sicherzugehen, ob das so ist, fehlt immer noch ein direkt (an den internen fritzbox-Anschlüssen analog oder isdn) angeschlossenes Telefon, das per avm sip-client mit dem fritzbox asterisk verbunden ist (und so eingestellt ist, dass es nur bei Anrufen auf dieser Internetrufnummer klingelt).

Bisherige Erfahrungswerte sind, dass so angeschlossene interne Telefone sauber funktionieren. Wenn in dieser Konfiguration die Probleme mit einseitigem/fehlendem Ton bei eingehenden analogen Anrufen auch auftreten, dann erst ist einigermassen sicher, dass es am chan_capi <-> analoger CAPI-controller liegt.

--------------------

@CTU
In v1.4.2 ist die aktuellste CAPI v1.0.1 enthalten ... in der v1.2.18 befindet sich noch die Version 0.7.x .

CHANGES

20070429
- asterisk: spblinux.de/fbox.new (only at fbox.new/ not, yet, at fbox/):
  - updated asterisk to 1.2.16, chan-capi-1.0.1, chan-sccp-20060408

Soll heissen, die auf fbox.new liegenden Asteriskversionen haben beide den neueren chan_capi.

spblinux

 

[CTU]

@spblinux:

a) ja genau
b) noch nicht getestet. Aber falls die gehen sollten, welche Rückschlüsse lässt das auf die eingehenden Anrufe zu ?
c) werde ich nochmal schauen, aber wenn ich mich recht entsinne, ging das "s" nur in Kombination mit immidiate=yes
d)Genau das will ich ja nicht, weil das nur die halbfertige Lösung ist, wie ich finde und ich damit mal von der fehlenden Rufnummerübermittlung abgesehen nur schlechte Erfahrungen gemacht habe (Echo, Ausfall etc ... )
e) Kannst du mir sagen, wo ich eine Anleitung finde, um analoge Geräte an den Asterisk anzuschließen ?

Bis dahin vielen dank :9

mfg,
CTU

 

[spblinux]

e) weiter oben ..., auch

spblinux