Asterisk hinter Lancom

Vielen Dank - ich teste es morgen auch gleich mit aus und werde berichten...
 
Per ISDN-Telefon (mit der alten Anlage) ist der Anruf jedoch immer erfolgreich
Eingebucht in den Lancom und der Lancom macht dann die Umsetzung auf VoIP/SIP?
In dem Fall solltest Du Dich beim Debuggen auf die Verbindung Lancom ↔︎ Digium Asterisk konzentrieren. Schade, dass es dafür keine vorgefertigten Anleitungen gibt. Vielleicht geht es auch gar nicht wegen irgendeinem Software-Fehler. Für Passiv-Leser: Wenn in Zukunft jemand auf diesen Thread hier stößt und in Folge der weiteren Recherchen dann doch eine Anleitung Lancom ↔︎ Digium Asterisk zu finden ist, bitte hier ergänzen!

diga, bei diesen Fehlerbildern kann ich Dir nur empfehlen den Lancom beiseite zu legen und eine Telekom Digitalisierungsbox Premium bzw. Smart (Bintec-Elmeg) zu holen, je nach der Anzahl benötigter ISDN-Busse. Digitalisierungsbox Basic wäre auch eine Option, aber das ist ein ganz anderer Sub-Hersteller (Zyxel Sphairon).
 
Die ISDN-Ports brauche ich nach der vollständigen Umstellung nicht mehr und gern würde ich beim Lancom bleiben - grunsätzlich schlecht scheint er ja nicht zu sein - doch anscheinend habe ich noch nicht die richtigen Worte gefunden, mit ihm zu kommunizieren.

Leider komme ich erst heut abend zum Testen, da die Anlage derzeit genutzt wird - werde dann auch ersteinmal den qualify_frequency testen.

Doch ist mir im Zuge der Änderung im qualify_frequency noch aufgefallen, dass ich bisher alle individuellen Endpoints für den Outbound zum Lancom (zugegeben etwas unhandlich, doch nötig für die korrekte Rauswahl mit der individuellen Rufnummer) zwar mit verschiedenen from_user-Einträgen ausgestattet hatte, aber aus dem Template alle mit dem selben contact (also nur der Kopfnummer 12345 zu dem einen SIP-Benutzer 12345# zum Lancom kommunizieren lasse.

Soweit wie ich das nun nach weiterer Recherche verstehe, ist der contact-Eintrag im aor die eindeutige Zuordnung und entscheidend im Invite für den Rückweg (bspw. auch für den PRACK). Vielleicht auch daher die Probleme mit dem 100rel, dass das Angebot "PRACK" zwar beim Gegenüber ankam, doch auf dem Rückweg (sofern unterstützt) es nicht wieder dem gleichen Channel zugeordnet wurde.
- Nur eine Vermutung aus meiner aktuellen Sicht -

Macht es aus diesem Gedanken heraus Sinn auch einen individuellen contact für jeden individuellen Outbound-Endpoint einzeln zu haben.
Legende: 192.168.2.1 = IP des Lancom - 12345 = Kopfnummer - 12345# = Sip-Benutzer auf dem Lancom
Zum Vergleich - bisher war es so:
Rich (BBCode):
[endpoint-ext-basic](!)
type=endpoint
aors=my_aor
...
from_domain=intern
outbound_auth=12345-Auth

[my_aor]
type=aor
contact=sip:[email protected]
qualify_frequency=0

; Durchwahl 117 ------------------

[117](endpoint-basic)
callerid=Tester <117>
auth=auth117
aors=117

[auth117](auth-userpass)
username=117

[117](aor-single-reg)

[my_endpoint_117](endpoint-ext-basic)
from_user=12345117

; Durchwahl 118 ------------------
[118](endpoint-basic)
callerid=Tester2 <118>
auth=auth118
aors=118

[auth118](auth-userpass)
username=118

[118](aor-single-reg)

[my_endpoint_118](endpoint-ext-basic)
from_user=12345118

Die Vorstellung / Idee geht in diese Richtung:

Rich (BBCode):
[endpoint-ext-basic](!)
type=endpoint
...
from_domain=intern
outbound_auth=12345-Auth

[my_aor_ext](!)
type=aor
qualify_frequency=240

; Durchwahl 117 ------------------

[117](endpoint-basic)
callerid=Tester <117>
auth=auth117
aors=117

[auth117](auth-userpass)
username=117

[117](aor-single-reg)

[my_endpoint_117](endpoint-ext-basic)
from_user=12345117
aors=my_aor_117

[my_aor_117](my_aor_ext)
contact=sip:[email protected]

; Durchwahl 118 ------------------

[118](endpoint-basic)
callerid=Tester2 <118>
auth=auth118
aors=118

[auth118](auth-userpass)
username=118

[118](aor-single-reg)

[my_endpoint_118](endpoint-ext-basic)
from_user=12345118
aors=my_aor_118

[my_aor_118](my_aor_ext)
contact=sip:[email protected]

Ist der Gedanke sinnvoll es zu testen, oder bringt es die Asterisk komplett durcheinander und ist total daneben?

Update: Hatte Hoffnung, doch hat das Problem sowohl mit dem definierten qualify_frequency, wie auch mit den spezifisch definierten contact-Einträgen, weiterhin bestand. Filtere ersteinmal die Traces vor und zeige in kürze mal die Unterschiede auf...

Update: Nach einer intensiven Analyse in Eigenregie (zunächst ohne hier riesige Traces zu posten) ist mir aufgefallen, dass die Wege der Pakete nicht so ganz zielgerichtet sind - das vermutlich nur aus dem Grund, da ich zwei binds über verschiedenen NICs nutze. Der Plan nun, jeweils mittels local_net und bind=0.0.0.0 die Pakete richtig zu lenken - vermutlich auch daher die Nebeneffekte, weil nicht alle Pakete dort ankommen, wo sie hin sollen... Werde es testen und berichten
 
Zuletzt bearbeitet:
Wenn du BBCode in Code Tags verwenden möchtest, praktisch auch für farbliche Hervorhebungen, dann nimm...
[code=rich][/code]

Beispiel:
Rich (BBCode):
Rot und Orange und Grün und Fett
 
  • Like
Reaktionen: diga
Geschafft - jetzt funktioniert alles wie gewünscht - wenig Änderung mit großer Wirkung. Die separate Definition der binds für out und inbound war keine gute Idee meinerseits - so ist es viel besser:
Code:
bind=0.0.0.0:5060
local_net={lancom_netz}.0/24
local_net={telefon_netz}.0/24
dann noch ein identify, den ich vermutlich bei all den tests entfernt hatte und nun läuft es problemlos auch mit direct_media=no - hoffe ich zumindest, ersteinmal noch ein paar Testtage abwarten, aber sieht jetzt im Trace alles viel zielgerichteter aus.

Nochmals vielen Dank für die vielen Tipps und die Mühe - echt spitzen Community hier...
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.