Asterisk hinter Lancom

[diga]

Hallo,
vorerst sorry dass ich gleich mit einer Frage ins Haus falle, doch bin ich etwas am verzweifeln und hoffe hier auf fachkundigen Rat...
Bin nun schon seit ca. 2 Wochen am tüfteln, ein Asterisk 17.6.0 so zu konfigurieren, dass dieser ausgehende Anrufe über den bereits konfigurierten Sip-Trunk auf einem Lancom 884VA schickt. Dafür habe ich auf dem Lancom sowohl eine SIP-PBX-Leitung (in der angehangenen PJSIP.conf > [Asterisk]) eingerichtet - die jedoch im LANMonitor noch "Transport not ready" / "Leitung nicht verfügbar" schreibt, was ich auch noch nicht so ganz verstehe - als auch auf dem Lancom einen SIP-Benutzer (in PJSIP.conf als [802] definiert) angelegt, an welchem sich die Asterisk bereits erfolgreich anmelden kann. Zudem gibt es auf dem Lancom eine Call-Route welche alle Anrufe jeglicher Nummern vom SIP-Benutzer (hier also 802) an den SIP-Trunk weiterreicht.

Versuche ich nun einen externen Anruf, gehen die Pakete jedoch nicht an den Lancom, sondern an eine ganz absonderliche IP-Adresse - TCP-Dump nachfolgend gezeigt:

11:46:35.548389 IP snomD385-938F68.dom.intern.41027 > 192.168.200.66.sip: SIP: INVITE sip:[email protected];user=phone SIP/2.0
11:46:35.550180 IP 192.168.200.66.sip > snomD385-938F68.dom.intern.41027: SIP: SIP/2.0 100 Trying
11:46:35.554922 IP 192.168.200.66.sip > snomD385-938F68.dom.intern.41027: SIP: SIP/2.0 180 Ringing
11:46:35.558325 IP 192.168.200.66.sip > 0.0.3.34.sip: SIP: INVITE sip:0123456789@802 SIP/2.0
11:46:36.060672 IP 192.168.200.66.sip > 0.0.3.34.sip: SIP: INVITE sip:0123456789@802 SIP/2.0
11:46:37.061697 IP 192.168.200.66.sip > 0.0.3.34.sip: SIP: INVITE sip:0123456789@802 SIP/2.0
11:46:39.061789 IP 192.168.200.66.sip > 0.0.3.34.sip: SIP: INVITE sip:0123456789@802 SIP/2.0
11:46:43.062211 IP 192.168.200.66.sip > 0.0.3.34.sip: SIP: INVITE sip:0123456789@802 SIP/2.0
11:46:45.564746 IP 192.168.200.66.sip > snomD385-938F68.dom.intern.41027: SIP: SIP/2.0 603 Decline

192.168.200.66 = Asterisk
192.168.2.1 = Router
0.0.3.34 = keine Ahnung

Kommunikation via Proxy ist definitiv möglich, weil dieser aktuell alles durchreicht - so auch bspw. die erfolgreiche Anmeldung des Benutzers... Habt ihr eventuell eine Idee - bin mittlerweile echt ratlos woran es noch liegen kann...

Meine aktuelle PJSIP.conf
Sollten Konfigurationen wiedersprüchlich oder totaler Unsinn sein - ruhig kritisieren, bin nach so viel herumprobieren etwas betriebsblind und hoffe auf ein Erfolgserlebnis

[global]
type=global
user_agent=Asterisk PBX
endpoint_identifier_order=ip,username
default_from_user=802

; ======================TRANSPORT
[simpletrans]
type=transport
protocol=udp
bind=0.0.0.0
allow_reload=yes
local_net=192.168.0.0/24
external_media_address=192.168.2.1
external_signaling_address=192.168.2.1
external_signaling_port=5060

; ======================ENDPOINT TEMPLATES
[endpoint-basic](!)
type=endpoint
transport=simpletrans
context=internal
disallow=all
allow=g722
allow=ulaw
allow=alaw
direct_media=no
rtp_keepalive=30

[auth-userpass](!)
type=auth
auth_type=userpass
password=1234

[aor-single-reg](!)
type=aor
max_contacts=1
remove_existing=yes

; =======================IN Lancom
[Asterisk]
type=endpoint
transport=simpletrans
context=from-external
disallow=all
allow=ulaw
aors=Asterisk
auth=Asterisk-Auth
dtmf_mode=inband
direct_media=yes

[Asterisk-Auth]
type=auth
auth_type=userpass
password=1234
username=Asterisk

[Asterisk]
type=aor
contact=sip:192.168.2.1:5060

[Asterisk]
type=identify
endpoint=Asterisk
match=192.168.2.1

; =======================OUT Lancom

[802]
type=registration
outbound_auth=802-Auth
server_uri=sip:[email protected]:5060
client_uri=sip:[email protected]:5060
retry_interval=60
forbidden_retry_interval=300
expiration=480
auth_rejection_permanent=false

[802-Auth]
type=auth
auth_type=userpass
password=1234
username=Asterisk

[802]
type=aor
contact=sip:[email protected]:5060
max_contacts=1
remove_existing=yes

[802]
type=endpoint
;context=from-external
disallow=all
allow=ulaw
auth=802-Auth
aors=802

[802]
type=identify
endpoint=802
match=192.168.2.1

; =======================EXTENSIONS

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

[auth117](auth-userpass)
username=117

[117](aor-single-reg)

...

Auszug meiner extensions.conf

exten => _00Z.,1,DIAL(PJSIP/802/sip:${EXTEN:1}@802, 120)
    ; same => n, DumpChan()
    same => n,Hangup()

 

[sonyKatze]

Kannst Du auf dem Digium Asterisk, auf dem Lancom oder mittels Switch dazwischen einen Paket-Mitschnitt ziehen? Damit könnte man Wireshark füttern. Damit müssten wir dann die echten SDP-Pakete sehen. Lancom bietet dafür die Möglichkeit einen Ethernet-Port als „Monitor“ einzurichten: WEBconfig → Konfiguration → Schnittstellen → LAN → Ethernet-Ports → irgendeinen → Interface-Verwendung. Bei anderen handelsüblichen Switchen heißt die Funktion oft „Port-Mirroring“.

Und noch eine Frage: Du arbeitest mit external_* in der Konfigurationsdatei. Wer macht denn das NAT zwischen Lancom und Asterisk? Wäre das meine Installation, hätte ich den Asterisk in das selbe Sub-Netz gepackt wie den Lancom. Aber selbst wenn Du ein weiteres Sub-Netz aufspannst, warum macht das ein weiterer Router und nicht der Lancom selbst? Oder anders formuliert: Aus der Sicht des Asterisk müsste der Lancom lokal, also im selben Sub-Netz sein.

Und noch eine Frage, diese aber eher aus Neugierde: Warum überhaupt ein Digium Asterisk? Du könntest das Snom Tisch-Telefon auch direkt im Lancom anmelden.

 

[diga]

Hallo,
ersteinmal vielen Dank für die Mühe...
Den vollständigen Paketmitschnitt (tcpdump) vom Asterisk kann ich gleich morgen posten, habe nur jetzt leider keinen Zugriff darauf. Bis zum Lancom kommt das Paket jedoch nicht, wegen der absonderlichen IP-Adresse.

Zwischen den beiden Netzen befindet sich ein Proxy, der üblicherweise den Traffic filtert und für NAT verantwortlich ist. Dieser lässt jedoch aktuell, zumindest für den Asterisk, alles durch. Habe diesem Umstand geschuldet, auch schon etwas mit der Konfiguration des outbound_proxy, local_net und den besagten external_*-Angaben herumgespielt, bin allerdings zu keinem besseren Ergebnis gekommen, wie das aktuell beschriebene. Hatte hier lange recherchiert, doch sind die Informationen zu pjsip recht rar. Gern nähere ich mich aber der Lösung auch schrittweise - die external_*-Angaben sollten demnach den Proxy beinhalten? Hatte ich bisher nicht mit gerechnet, insbesondere weil die Registrierungsanfragen vom 802 zum Lancom ohne Probleme gelangen - doch sofern der Proxy eine Ursache sein könnte, kann ich morgen auch den Asterisk vorübergehend in das gleiche Netz wie den Lancom hängen und berichten.

Warum Asterisk:
Yep, der Lancom ermöglicht sehr viel. Doch hätte ich gern etwas, wo etwas mehr zur Konfiguration der Warteschleifen / Ring-Groups / Voicemail etc. möglich ist. FreePBX hatte ich auch schon getestet, doch ist es mir vorerst wichtig, das Prinzip im Hintergrund zu verstehen, bevor ich mir eine schicke Oberfläche genehmige. Bin aktuell noch in der Entscheidungsphase, wie die neue TK-Anlage umgesetzt werden könnte und habe mir als Testgerät dieses Tischtelefon zugelegt. Ob dieses dann auch später in der Produktivumgebung eingesetzt wird, weiß ich noch nicht (brummt aktuell sporadisch - vielleicht aber auch durch Firmwareupgrade behebbar).

 

[diga]

Sooo - wie versprochen hier der vollständige Dump für Wireshark... Werde anschließend mal den Asterisk direkt in das gleiche Netz hängen und berichten.
VG

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Das umbauen war leider nicht von Erfolg gekrönt - das Problem blieb das gleiche - doch weiß ich jetzt wo die Adresse "0.0.3.34" herkommt. Er scheint die 802 in der Dial-Anweisung (hinter dem @) als IP-Adresse zu interpretieren und nicht wie gewünscht, den in PJSIP und im Lancom definierten Benutzer zu verwenden... Gibt es hierfür eine bessere Alternative der Dial-Anweisung, die über den SIP-Benutzer 802 auf dem LANCOM telefoniert?

VG

 

[sonyKatze]

An Deiner Stelle würde ich für jene Frage einen neuen Thread aufmachen. Ich müsste das jetzt erst wieder testen (alles schon mal gemacht, aber alles merke ich mir auch nicht). Müsste das in Deinem Fall nicht einfach Dial(PJSIP/${EXTEN}@802) wie hier beschrieben sein? Das mit „sip:“ ist nur für SIP-URIs … mein Tipp: Nenn den „802“ irgendwie um, z.B. in „my_provider“. Dann wird das allein vom Lesen her bereits „logischer“. siehe unten Post #9

Zwischen den beiden Netzen befindet sich ein Proxy, …

Welche Funktion soll der irgendwann einmal haben? Für VoIP/SIP gilt: Wenn möglich, so wenig NAT wie nötig.

… Lancom … Warteschleifen / Ring-Groups / Voicemail

Müsste eigentlich alles auch mit dem LANCOM Voice-Call-Manager gehen, aber vermutlich willst Du noch mehr.

 

[diga]

Yep, die in der Doku beschriebenen Dial-Anweisungen habe ich bereits alle durchprobiert - so auch den oben genannten - leider erhalte ich dabei immer nur einen 404 Not Found - scheint wohl so, dass er den angelegten Nutzer nicht findet bzw. die gewählte externe Nummer auf dem Lancom nicht zuordnen kann... Werde nun einen anderen Weg bestreiten und den Lancom aus der Gleichung nehmen... @sonyKatze: Hab dennoch tausend Dank.

VG

 

[sonyKatze]

Kam der Status 404 vom Lancom? Dann müssten wir da schauen. Lancom würde ich nicht rausnehmen. Jedenfalls wenn Dein VoIP/SIP-Anbieter einer der großen Alten ist. Erkläre ich gerade lang und breit in einem Parallel-Thread … Ich würde die ganzen Abschnitte [ und ] neu benennen, z.B. mit einem Prefix, my_transport oder so. Nicht das der Konfigurationsparser hier einen Software-Bug hat. siehe unten Post #9

 

[diga]

Hi,
yep - das ist eigentlich auch der Grund warum ich sehr gern den Lancom als Vermittler (in meinem Fall ist es der rosa Riese) behalten würde. Doch will es einfach nicht funktionieren. Zudem ist es auch so, dass ich aktuell den Lancom nur mit Samthandschuhen anfassen kann, da dieser tagsüber für die Telefonie bereits als Vermittler zu einer alten ISDN-Anlage fungiert. Hierfür gibt es eigene Call-Routen und Mappings, die dann ISDN auf SIP-Trunk und umgekehrt vermitteln.

Die vorgeschlagenen Änderungen habe ich natürlich umgesetzt und der Asterisk scheint auch einen INVITE zum LANCOM abzusetzen (gern kann ich hier auch nochmals einen Dump und die aktuelle pjsip posten). Der Lancom quittiert das jedoch nur mit einem müden 404 Not Found. Der besagte SIP-Benutzer ist jedoch erfolgreich registriert und mit dem vorgeschlagenen Dial-Befehl, sollte er ja theoretisch über diesen vermitteln. Anscheinend wird aber der Benutzer nicht mit übertragen bzw. verwendet. Üblicherweise kommt ja immer zuerst der Benutzername und im Anschluss nach dem @ die Adresse. Beim dokumentierten Dial kommt jedoch die gewählte Telefonnummer, dann das @ und zum Schluss der Benutzer. Vermutlich versucht der Lancom die gewählte Nummer als Benutzer zu finden - was ja in diesem Fall Unsinn wäre.

Edit: Sorry, bin heut nicht dazu gekommen - werd es am Montag nochmal probieren - VG

 

[sonyKatze]

Aus reiner Neugierde: Was hast Du überhaupt vor? Willst Du
a) ISDN in Deinem Heimnetz durch eine reine VoIP/SIP-Landschaft ersetzen (Umstellung) oder
b) kaputte ISDN-Telefone ausrangieren und diese nicht wieder mit ISDN- sondern mit VoIP/SIP-Telefonen ersetzen (Parallelbetrieb)?

Zurück zu Deinem Szenario, welches ich nachgebaut habe. Auch hier erhalte ich einen Status 404. Lancom LCOS 10.42 erfordert, dass:
a) vor dem SIP-INVITE ein SIP-REGISTER erfolgreich gewesen war, und
b) im SIP-INVITE der selbe Header Contact wie in SIP-REGISTER verwendet wird (User, Domain Port), und
c) der Header From im SIP-INVITE muss die SIP-Domain (oder dessen IPv4) auf dem Lancom entsprechen. Beispiel: Du hast im Lancom einen SIP-Benutzer „sip-user-1“ angelegt. Dann muss From: <sip:sip-user-1@intern>;… in Wireshark zu sehen sein. Wobei „intern“ der Standardwert seitens Lancom ist. Den kannst Du ändern (SNMP-ID 2.33.2.1). Oder Du nimmst direkt die lokale IP-Adresse.

Die ersten beiden Anforderungen bekommst Du mit Asterisk/chan_pjsip automatisch, wenn Du ein Kontext type=registration anlegst. Die dritte Anforderung bekommst Du, indem Du im Endpoint der Registration den Parameter from_user, from_domain, outbound_auth und allow = alaw setzt. So verschwand mein Status 404.

Der outbound_auth ist nötig, denn der Asterisk geht nicht zurück zum Kontext Registration und dessen outbound_auth: „Endpoint: … Unable to create request with auth. No auth credentials for realm(s) 'intern' in challenge.“ Folglich muss outbound_auth sowohl in der Registration als auch dem Endpoint der Registration stehen. So klappt dann die Proxy-Authorization.

Das allow ist nötig, weil Asterisk als Standardwert einen leeren String nimmt: „Status: 406 SDP Not Acceptable“. Leer bedeutet für Asterisk überhaupt keinen Audio-Codec anzubieten, was nicht funktionieren kann. Solange Du noch ISDN parallel fährst, würde ich nur einen Audio-Codec angeben, also den selben wie in ISDN = alaw. Wenn Du später vollständig auf VoIP/SIP migriert bist, kannst Du zusätzlich mit G.722 experimentieren.

So … klappt es nun bei Dir? Hier meine extensions.conf:

[default]
exten => _.,1,Dial(PJSIP/${EXTEN}@my_endpoint)

und meine pjsip.conf:

[global]
type = global
keep_alive_interval = 0 ; seconds, double CRLF as keep-alive mechanism

[my_registration]
type = registration
transport = my_transport
outbound_auth = my_auth
client_uri = sip:sip-user-1@intern
contact_user = sip-user-1
server_uri = sip:intern
line = yes ; otherwise "An endpoint has been specified on outbound registration ... without enabling line support"
endpoint = my_endpoint ; required for "qualify_frequency", "from_domain", and "from_user"

[my_transport]
type = transport
bind = 0.0.0.0
protocol = udp
ca_list_path = /etc/ssl/certs/
verify_server = yes
method = sslv23
cos = 3
tos = cs5

[my_auth]
type = auth
password = Password#9321
username = sip-user-1

[my_endpoint]
type = endpoint
aors = my_aor
allow = alaw
from_domain = intern
from_user = sip-user-1
outbound_auth = my_auth
cos_audio = 5
cos_video = 4
tos_audio = ef
tos_video = af41

[my_aor]
type = aor
contact = sip:sip-user-1@intern
qualify_frequency = 0 ; seconds, SIP-OPTIONS as keep-alive mechanism

[desk-phone-1]
type = endpoint
auth = desk-phone-1
aors = desk-phone-1
allow = alaw
cos_audio = 5
cos_video = 4
tos_audio = ef
tos_video = af41

[desk-phone-1]
type = auth
password = Password#9321
username = desk-phone-1

[desk-phone-1]
type = aor
max_contacts=999

Den Wert intern solltest Du mit der lokalen IPv4 ersetzen – also in Deinem Fall mit 192.168.2.1 –, denn ich hatte hier erhebliche Probleme mit dessen DNS-Auflösung. Und obwohl der SIP-Server im Lancom auch über die globale IPv6-Adresse bzw. eine bei Loopback hinterlegte IPv6-Adresse (ULA) ansprechbar ist, bekommt man darüber nur Status: 400 Missing Mandatory Headers. Der Wert intern geht zwar dann doch auch über IPv6, aber dann wieder die DNS-Auflösungserscheinungen …

sip-user-1 ist der „SIP-Benutzer“ im Lancom. In Deinem Fall ersetzt Du das mit Asterisk. Und desk-phone-1 ist der „Nutzerkennung“ im Snom-Tischtelefon. In Deinem Fall ist das offenbar ebenfalls Asterisk.

Das Beispiel könnte besser sein, denn besondern im Kontext transport unterstützt sowohl das Snom, Asterisk also auch Lancom SIP-over-TLS. Wenn gewünscht, erkläre ich das.

 

[diga]

Hi,
hab schoneinmal tausend Dank für die Mühe - "echt krass", zu neudeutsch... Geb mal durch was ich Dir gutes tun kann
Habe vorhin auch noch etwas mit den vorherigen Hinweisen herumgespielt und bin leider noch nicht über den 404 hinweggekommen - ausgehend von deiner PJSIP muss ich noch ein paar Änderungen vornehmen und werde auch meine PJSIP inkl. der Lancom-Settings posten, sobald es erfolgreich war.Vielleicht hilft es ja anderen mit den gleichen Problemen...

Weitere Verwendung: Die bisherige TK-Anlage zeigt nunmehr alle Anzeichen eines baldigen Totalausfalles. Noch funktioniert sie, doch gibt es rauschen, knacksen oder Probleme mit den Flash-Zeiten. Zudem haben auch einige Ports bereits vollständig den Dienst eingestellt. Ziel ist es daher, vorerst parallel etwas Neues umzusetzen, um bald die TK-Anlage dem Museum zu spenden. Sobald alles in der Testumgebung funktioniert, sollen dann natürlich auch neue IP-Telefone eingesetzt werden. Die verwendeten ISDN-Ports / Mappings würde ich dann natürlich wieder deaktivieren / löschen...

VG

----

Edit: yeah - nun taucht zumindest ein Anruf im Call-Manager des LANCOM auf - allerdings leider noch mit der Nachricht "Gegenstelle defekt" - ich tüftle mal weiter und berichte später nochmal...



Edit2: Nachdem ich den Asterisk nun nocheimal in das gleiche Netz gehangen hatte, war es vollbracht - das Zieltelefon hat geklingelt - welch Wunderwerk... Gegenstelle defekt war offensichtlich die noch nicht funktionierende Rückleitung via SIP-PBX....
Werde jetzt ersteimal freudentänze abhalten, die ganzen Probe-Settings aufräumen und versuchen die Einstellungen zu analysieren und danach schreibe ich nocheinmal einen zusammenfassenden Post dazu.
Nochmals tausend Dank dafür.


Edit3:

Wie versprochen, hier nochmals zusammenfassend der Aufbau.
Bei der Konfiguration handelte es sich um einen LANCOM R884VA mit der LCOS-Version 10.12.0147 (nachfolgend unter der IP-Adresse 192.168.2.1), der die Verbindung zum Sip-Trunk der DTAG herstellt. Der Lancom sollte nun von und zu einem Asterisk (nachfolgend unter der IP-Adresse 192.168.2.66) vermitteln.

Wichtig, sodass die Konfiguration funktioniert: Für die SIP-PBX scheint es zwingend erforderlich, dass der Asterisk im gleichen Netz ist, bzw. in der definierten Domäne des Lancom auffindbar ist.

Konfiguration Lancom:

Dazu wurde zunächst im Webfrontend des LANCOM (geht natürlich auch über LanConfig) unter Konfiguration > Voice-Call-Manager > Leitungen > SIP-PBX-Leitungen > Hinzufügen eine selbige mit folgenden Einstellungen definiert:

Eintag aktiv: check
SIP-Domäne/Realm: 192.168.2.66
Registrar (optional): 192.168.2.66
Port: 5060
Standard-Passwort: geheim
Erlaube eingehende UDP-Pakete: Über LAN
SIP-Proxy-Port: 0
Routing-Tag: 0
Anruf-Präfix: leer
Leitungs-Präfix: leer
Überwachungsmethode: Automatisch
Überwachungsintervall: 60
Vertrauenswürdige Leitung: check
Übermittlungsmethode: RFC3325
DTMF-Signalisierung: Telefon-Events - Rückfall auf In-Band

Zusätzlich wurde unter Konfiguration > Voice-Call-Manager > Benutzer > SIP-Benutzer > Hinzufügen ein SIP-Benutzer mit folgenden Einstellungen definiert:

Eintrag aktiv: check
Interne Rufnummer: 802
Authentifizier.-Name: 802
Passwort: geheim
Zugriff vom WAN: nicht erlaubt
Gerätetyp: Telefon
DTMF-Signalisierung: Telefon-Events - Rückfall auf In-Band
Transportprotokolle: UDP+TCP+TLS
Sprach-Verschlüsselung: Bevorzugt

Zuletzt konnte bisher der Outbound mit folgender Call-Route (angelegt unter Konfiguration > Voice-Call-Manager > Call-Router > Call-Routen > Hinzufügen) erfolgreich getestet werden:

Eintrag aktiv/Defaultroute: Aktiv
Priorität: hohe Zahl für höchste Priorität - bei mir 3
Gerufene Nummer: #
Rufende Nummer: +49123456789#
Ziel-Nummer: #
Rufende Domäne: intern
Quell-Leitung: USER.SIP

Konfiguration Asterisk

In der PJSIP sieht es sehr ähnlich zum vorherigen Lösungspost von sonyKatze aus, habe nur vorerst die TLS-Verschlüsselung rausgenommen - dennoch der Vollständigkeit wegen, auch hier nocheimal beigefügt

[global]
type=global
user_agent=Asterisk PBX
keep_alive_interval=0

; ======================TRANSPORT
[my_transport]
type=transport
protocol=udp
bind=0.0.0.0

; ======================ENDPOINT TEMPLATES
[endpoint-basic](!)
type=endpoint
context=internal
allow=alaw

[auth-userpass](!)
type=auth
auth_type=userpass
password=geheim

[aor-single-reg](!)
type=aor
max_contacts=1
remove_existing=yes

[mytrunk]
type=registration
transport=my_transport
outbound_auth=mytrunk-Auth
client_uri=sip:[email protected]
contact_user=802
server_uri=sip:192.168.2.1
line=yes
endpoint=my_endpoint

[mytrunk-Auth]
type=auth
auth_type=userpass
password=geheim
username=802

[my_endpoint]
type=endpoint
aors=my_aor
allow=alaw
from_domain=intern
from_user=802
outbound_auth=mytrunk-Auth

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

; =======================EXTENSIONS

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

[auth117](auth-userpass)
username=117

[117](aor-single-reg)

Sollte etwas kontraproduktiv sein, bitte korrigieren, doch so funktionierte es ersteinmal
VG

 

[sonyKatze]

Sieht doch gut aus.

Nur bei der Call-Route im LANCOM Router hätte ich statt einem „aktiven“ Eintrag die Default-Route – Standard-Leitung genommen. Dort musste ich lediglich die Ziel-Leitung auf eine meiner SIP-Leitungen ändern.

Und der LCOS-Stand: ftp://ftp.lancom.de//LANCOM-Archive/LC-R884VA/
Leider pflegt Lancom für T-Systems nicht alle Software-Branches parallel wie bei den „eigenen“ Modellen. Daher musst Du bei einem R-Modell wie Deinem immer auf die neuste Firmware springen, aktuell 10.34.0100. Wenn Du unbedingt auf 10.12.xxxx bleiben willst, dann nimm bitte wenigstens 10.12.0442. Mit einem LANCOM 884 bzw. LANCOM 1784VA hättest Du auch 10.12.0787 zur Wahl. Brauchst Du überhaupt vier ISDN-Anschlüsse? Wenn nicht, würde ich mir an Deiner Stelle einen LANCOM 883 in eBay schießen. Die wechseln nicht im Sofort-Kaufen sondern als Auktion für weniger als 75€ den Besitzer. Mit so einem Modell hast Du immer die neuste Release und kannst auch bei Betas mitmachen.

 

[diga]

Stimmt - das fehlt in meiner Zusammenfassung, ist bei mir ebenfalls erforderlich gewesen: Als Ziel-Leitung der Call-Route ist der eingerichtete SIP-Trunk eingestellt.

LCOS Stand - yep, der Lancom ist schon etwas betagt. Doch wenn alles gut geht, brauche ich anschließend keinen der ISDN-Ports - auf jeden Fall eine Überlegung wert - Danke...

 

[sonyKatze]

Nicht das wir uns missverstanden … Dein Lancom Router ist top-aktuell. Über „WEBconfig → Extras → Datei-Management → Eine neue Firmware hochladen“ kannst Du die aktuelle LCOS 10.34 einspielen. Danach aktualisiert sich Dein Router auch selbständig; das kam erst mit LCOS 10.20. Was ich lediglich sagen wollte: Dein LCOS ist noch aus November 2017, ohne die vielen Security-Updates seitdem.

Dank für die Mühe

Gern geschehen. Aber mich hat das ebenfalls interessiert – auch weil ich das in dem anderen Thread empfahl. Und im Grunde war es lediglich die from_domain. Leider brauchen viele SIP-Server dies. Trotzdem habe ich das mal an Lancom gemeldet, denn normal ist das nicht. Umso erstaunlicher, dass die from_domain in Asterisk/chan_psjip so kompliziert zu setzen ist. In Asterisk/chan_sip war das einfacher; war aber auch dort nicht das Standard-Verhalten.

 

[diga]

Kleiner Zusatz für alle die ähnliches Versuchen: Bei der DTAG sollte derzeit als Codec g722 gewählt werden, sonst klingelt es nur und beim Abnehmen ist Stille.


Hätte allerdings nochmals eine Frage ob es in der zuvor beschriebenen Konfiguration einen Trick gibt, die Rufnummer beim Rauswählen festzulegen. Derzeit wird ausschließlich die Hauptnummer gesendet und nicht wie gewünscht die Durchwahl. Habe hierzu bereits folgendes getestet - allerdings leider ohne Erfolg:

pjsip.conf

[my_endpoint]
type=endpoint
direct_media=no
aors=my_aor
allow=g722
allow=ulaw
allow=alaw
from_domain=intern
from_user=802
outbound_auth=802-Auth
dtmf_mode=rfc4733
trust_id_outbound=yes
send_pai=yes
send_rpid=no

extensions.conf

exten => _00Z.,1,NoOp()
    same => n, Set(CALLERID(all)="123456117" <123456117>)
    same => n, Set(CALLERID(num)=123456117)
    same => n, Set(CALLERID(name)=123456117)
    same => n, Set(PJSIP_HEADER(add,P-Asserted-Identity)="<sip:123456117>")
    same => n, Ringing
    same => n, Dial(PJSIP/${EXTEN:1}@my_endpoint,60,r)
    same => n, Hangup()

Dem Test geschuldet, sind hier einige Angaben redundant, doch lässt sich der Lancom nicht darauf ein.
Als Eintrag im SIP-Mapping (LANCOM) für den Outbound ist derzeit ausschließlich folgender Eintrag vorhanden: 123456#. Theoretisch wäre nach meinem Verständnis nur die Übermittlung der Durchwahl (im Beispiel die 117) nötig, doch auch diese Angabe hatte keinen Erfolg. Für eine Idee wäre ich sehr dankbar.

VG

Edit:
Lt. Lancom-Trace sendet er immer nur die interne Benutzernummer an die DTAG - also im From steht derzeit

From: <sip:[email protected];user=phone>

und der P-Asserted-Identity-Header kommt zwar beim Lancom eingangs an, doch wird er anschließend ignoriert.

---------------------------------
Update:
Nach einigen Versuchen die Rufnummer zu übertragen, bin ich nun soweit, dass ich die zu sendende Nummer über die from_user-Einstellung setzen kann. Das gelang, nachdem ich einen SIP-User mit der Kopfnummer und einem anschließenden # definiert habe. Das ging bisher nicht via Webfrontend (Lösungsweg unten), doch nachdem das erledigt war, bin ich schon einen Schritt weiter. Egal was ich nun im from_user an die Kopfnummer anhänge, wird dies auch beim angerufenen angehangen. Nun versuche ich das über den Dialplan zu steuern. Versuche via PAI oder RPID im PJSIP_HEADER schlugen fehl - er richtet sich stur nach der Einstellung im from_user. Klar kann ich nun ne Menge Endpoints anlegen, bei denen sich jeweils nur das from_user-Feld unterscheidet, aber schön ist das nicht. Sofern das ab diesem Punkt üblich ist, gebt mir bitte ein Zeichen, doch es wirkt irgendwie unhandlich. Ich tüftle weiter und werde berichten. Sofern jemand eine Idee hat, immer gern.

Achtung: Bei meiner derzeitigen Version der LANCOM-Firmware ist in der WebConfig das Anlegen eines Benutzers mit # nicht gestattet - muss das von sonyKatze bereits vorgeschlagene Upgrade unbedingt demnächst mal durchführen, welches auch diesen Bug sicher behebt. Mittels der Software LanConfig ließ sich dieser Benutzer aber auch bei meiner derzeitigen Version anlegen.

 

[Nili]

Hmm, ich betreibe seit Jahren einen Asterisk, einen embedded Freepbx hinter einem Lancom und den wiederum teilweise hinter speedport hybrid.
ich fahre sowohl gemischt ISDN als auch voip als Anlagenanschlüsse.
Telekom hat meinen ISDN Anlagenanschluss verloren nachdem sie meinen VDSL Anschluss seinerzeit nicht mehr mit meinem IDSN-Anlagenschluss kombinieren wollte weil es nicht ginge (ging zwar jahrelang, aber lt Platform nicht gewünscht). wie auch immer aus ISDN wurde ein Anlagenanschluss bei einem anderen Provider mit dem ich sehr zufrieden bin. Hintergrund war auch eine Empfehlung des Novizen Leitungs-Provider und Voip-Provider zu trennen. (Die Telekom Voip Anschlüsse sind sehr gering fehlertolerant insofern manchmal schwer zu administrieren. Nomadisch nutzbare Provider sind da hilfreicher, einige bieten Anleitungen für diverse Hard- und Software (z.B. Asterisk, Lancom ect. und sind bei Ausfall des Kabels auch über Mobilfunk nutzbar.)

Nun zur Technik:
egal ob ISDN oder Voip Provider, deine Nebenstellen werden vom Asterisk verwaltet. Die übergabe erfolgt als Pbx an den Lancom. Es ist zweckmässig sie im gleichen Netz zu haben, aber nicht zwingend. Ich habe in D einen eigenes Vlan mit dem vorteil Nebestellennr = letztes postition im Netzwer z.B. 192.168.2.44 ist nebenstelle 44. macht sich einfach wenn ich die Nebenstelle administrieren will.
Die ausgehende Rufnummer wird vom Asterisk generiert. Bei mir ist Nebenstelle = Nebenstennummer. Beim Asterisk definierst Du wie Du die Durchwahl funktioniert. Du kannst nur die Nebenstellennummer senden oder auch die gesammte Nummer.
einschliesslich Ländervorwahl. Das ist dem Asterisk ganz gleichgültig.
Du richtest als pbx die Verbindung zum Lancom an. mit dem Lanmonitor kannst du sehen, ob der Asterisk und der Lancom connectet sind.
Der Lancom muss deine Nebenstellnummer ect nicht kennen. Für den Lancom ist das kein User, sondern die Durchleitung an eine PBX. egal ob ISDN oder Voip.
Mit dem Lancom stellst Du dann die Verbindung zum Provider her. Hier kommt es jetzt drauf an, was der Provider zulässt.
Ich hatte seinerzeit bei der Telekom einen Isdn Anlagenanschluss und kein ClipNoScreen. Da meine ich habe nur die Nebenstellennr. übertragen und nicht die komplette Rufnummer mit LdKz. Bei meinen Voip Provider habe ich ClipNoScreen und sende die komplette Nummer inkl. Ldz, Ort Rufnummer + Nebenstelle. Ich benutze bei meinen Providern teilweise Trunk, aber auch Link als Einstellung. Wird vom Asterisk nur die Nebenstellennr gesendet, erfolgt die Ergänzung im Lancom durch das SipMapping.
Ob es dann über ISDN oder einen Provider rausgeht wird im Callrouting definiert. Genauso wie ob die reinkommenden Ruf an die PBX (Asterisk) oder anders definierte Nebenstellen geht. Als Nebenstelle zählt alles, was nicht an die PBX(Asterisk) geleitet wird.
Das System ist inzwischen seit Ewigkeiten weitestgehend gleich. Zu Beginn habe ich reinkommend ISDN mit 6 Kanälen an der 1724 genutzt und rausgehend überwiegend über Voip. Dect Telefone sind mit Mitel über SipOverIp an den Asterisk professional angebunden (nicht auf 6 begrenzt). Insofern ist die Version relativ belanglos.

Den Vorteil sehe ich, ich babe niemanden in meinem Netz. Der Asterisk kann nicht angegriffen werden. Ich habe keinen Nat dazwischen, was alles in der Konfiguration des Asterisk berücksichtigt werden muss.

Wie Du die Rufnummern übertragen musst, ist wieder Providerabhängig. Inige nehmen als was ihnen angeboten wird andere beharren auf ihr System.

Zuletzt: Probieren geht über Studieren.

 

[diga]

Hab ebenfalls vielen Dank für die ausführlichen Hinweise.
Ja, befinde mich da noch enorm im Lernprozess, doch obgleich die Wochen hart waren, verstehe ich das System schon um einiges besser - auch Dank der Beiträge hier im Forum / Post. Vielleicht werde ich es mit den gewonnenen Erkenntnissen nochmals ohne Nutzer probieren - das gelang mir eingangs nicht - doch würde ich vorerst die Lösung via SIP-Benutzer testen - so als Fallback.

Meine Umsetzung ist derzeit noch nicht sonderlich elegant, doch habe ich nun jeder Extension einen eigenen from_user-Eintrag gegönnt, sodass das Senden/Aufbereiten der Rufnummer im Endpoint der PJSIP und final vom Lancom / CallRouter übernommen wird. Das funktioniert soweit schon sehr gut und der inbound war vergleichsweise recht schnell umgesetzt.

Dennoch gibt es "Luft nach oben", wie man so sagt. Bspw. wird ein CANCEL (wenn der Nutzer noch vor der Rufannahme auflegt) nicht an das Telefon weitergereicht und es klingelt bis zum Ende der Zeitvorgabe des DIAL. Habe hierzu schon einiges gelesen, dass die IP des INVITE identisch zum CANCEL sein muss (was gegeben ist), oder die damalige Einstellung in der SIP mit pedantic=yes (gibts leider in PJSIP nicht) das Problem lösen könnte - der Lancom weiß vom Abbruch, doch stellt er dies leider nicht an die Asterisk durch. Trage ich in der Extension jedoch direkt bei Rufeingang ein Answer ein, wird der Bye durchgestellt und das Telefon gibt ruhe... Schon merkwürdig.

Möglich dass sich das Problem bereits mit dem besagten Firmwareupdate löst, worauf ich derzeit noch hoffe, doch muss ich mich zu diesem "Eingriff" noch etwas gedulden, habe hier etwas Bauchschmerzen da ich schon viele schlechte Erfahrungen mit Firmwateupgrades gemacht habe. Aber bald werde is es wagen...
Sofern die derzeitige Umsetzung das Problem danach immernoch hat, würde ich mich nochmal ohne SIP-Benutzer - also rein über die PBXLine auf dem Lancom versuchen.

VG


Achso - kleine Korrektur um keine Halbwahrheiten zu verbreiten - der Codec g722 ist natürlich nicht von der DTAG wie eingangs vermutet, lag mehr an meinem Test-Endgerät welches die Verbindung eingeleitet hat - das scheinen die anrufenden Endgeräte festzulegen / auszuhandeln - bisher hatte ich bei verschiedensten Anrufern sowohl ulaw, alaw und eben das g722 - müssen also alle im allow stehen, sonst hört man ggf. nix.


Edit: Das Firmwareupgrade auf die Version 10.34.0168 hat die zuvor erwähnte "Kinderkrankheit" des fehlenden CANCEL nun auch behoben. @sonyKatze: Nochmals vielen Dank für den Hinweis...

 

[diga]

Habe leider noch ein dubioses Problem an welchem ich nun schon wieder ca. 2 Wochen nicht weiterkomme. Habe bereits das halbe Internet durchsucht und vieles versucht, doch nichts hilft. Vielleicht gibt es ja noch einen Tipp oder eine Möglichkeit der Analyse.

Nach der Grundkonfiguration habe ich nun die gesamte Asterisk soweit, dass sie nahezu problemlos funktioniert. Sowohl Outbound wie auch Inbound. Dennoch habe ich spezielle Nummern - derzeitiges Testobjekt ist ein iPhone mit einer Telekom-SIM, wo der INVITE bis zum RINGING im Outbound noch hervorragend funktioniert, doch das Abnehmen seitens des Angerufenen keinen RTP-Stream auslöst. Das Snom klingelt nach kurzer Pause weiter und löst nach ca. 20Sek. einen Internal Server Error (500) aus. Am iPhone und der Codecaushandlung scheint es nicht zu liegen, da mit einer anderen Sim von Vodafone alles bestens läuft und der alaw erzwungen wird. Versteht sich hier die Telekom intern nicht? Im Lancom-Trace ist bei beiden zunächst auch alles identisch, doch weicht es ab den folgenden Zeilen voneinander ab:

[Callmanager] 2021/01/21 18:06:40,145  Devicetime: 2021/01/21 18:06:40,100 [SIP-Provider] : ProvisionalResponseEarlyMediaHndl  --  stub: 071bcd88 - call-id: 3640229205@00a0573c0dcb, local tag: -1142417972-1344161116, remote tag: f5608c86  -->  is active: yes, media status changed: no, media status: 3


[Callmanager] 2021/01/21 18:06:40,145  Devicetime: 2021/01/21 18:06:40,101 [SIP-Provider] : - info       : No Session-Expires header available -> stop session timer


[Callmanager] 2021/01/21 18:06:40,145  Devicetime: 2021/01/21 18:06:40,101 [SIP-CALL] : stop session timer for call 0x07031480

Anschließend kommt es dann nur noch zu einigen Verbindungsversuchen und dem letztendlichen Abbruch vom SIP-Provider. Ruft dieses Smartphone auf der Asterisk an, gibts übrigens keine Probleme im Verbindungsaufbau.

Daraufhin habe ich u.a. bereits mit dem flag timers=yes/no und lt. einigen Aussagen in Foren das sRtp seitens Benutzereinstellung auf dem Lancom (per Einstellung Ignorieren) und in der Asterisk (nur mit Standardeinstellungen per UDP Port 5060) deaktiviert. Doch alles hilft nicht - das Problem bleibt bestehen.

Meine derzeitige PJSIP (etwas eingekürzt für den Outbound) sieht wie folgt aus. Durch das ganze Gespiele/Herumprobieren sind sicher auch ein paar Dinge unlogisch, doch was sich hier beißt, sehe ich irgendwie nicht) - Achso - ja die Telefone müssen leider in einem anderen Netz hängen, als der Lancom - doch Asterisk kennt sie ja beide, was eben auch meistens funktioniert.

[global]
type=global
user_agent=Asterisk PBX
keep_alive_interval=0

; ======================TRANSPORT
[my_transport]
type=transport
protocol=udp
bind={Asterisk-IP-Im-Netz-Der-Telefone}
cos=3            
tos=cs5    

[my_transportout]   
type=transport       
protocol=udp
bind={AdresseDesAsteriskImNetzDesLancom-eth1}
cos=3           
tos=cs5

[endpoint-ext-basic](!)
type=endpoint
dtmf_mode=rfc4733
aors=my_aor
disallow=all       
allow=alaw
from_domain=intern
from_user={SIP-Benutzer}
outbound_auth={SIP-Benutzer}-Auth
trust_id_outbound=yes
cos_audio=5
cos_video=4
tos_audio=ef
tos_video=af41
timers=no

[my_aor]
type=aor
contact=sip:{SIP-Benutzer}@{Lancom-IP}
qualify_frequency=0

; =======================EXTENSIONS

; 117 ------------------
[117](endpoint-basic)
callerid=Tester <117>
auth=auth117
aors=117
...
[my_endpoint_117](endpoint-ext-basic)
from_user={SIP-Benutzer}117
...

Möglicherweise hängt es mit diesen Einstellungen zusammen (lt. Asterisk-Wiki):

timers_min_se=90
timers=yes
timers_sess_expires=1800

aber noch nirgends gesehen, dass man so etwas manuell setzen müsste... Tappe hier halt etwas im dunkeln

Ich hoffe es gibt hierzu einen Rat, wie ich hinter dieses Rätsel kommen kann.

Zumal auch etwas komisch, doch kann ich im Template [endpoint-ext-basic](!) die geplante Konfiguration transport=my_transportout nicht setzen, da damit der Nutzer auf dem Lancom plötzlich nicht mehr gefunden werden kann... Ohne funktioniert es aber - vermutlich auch noch ein Denkfehler...

Vielen Dank schonmal fürs Lesen
VG

UPDATE: Vermutlich habe ich es nun zunächst gelöst - vermutlich gab es Probleme mit dem 100rel / PRACK - im Outbound deaktiviert und das Problem war gelöst

 

[sonyKatze]

seitens des Angerufenen keinen RTP-Stream auslöst

Hier musst Du mal vor der Firewall des Lancom den Datenverkehr mitschneiden.

1. Kommt dort RTP irgendwie am Lancom an?
2. Schickt der Lancom das RTP raus?
3. Ist der Lancom Deine Firewall und auch Dein DSL-Router?
4. Was passiert, wenn Du ein ISDN-Telefon direkt in den Lancom steckst und darüber (und nicht über den Digium Asterisk) mit diem Ziel telefonierst?

100rel / PRACK - im Outbound deaktiviert

Auf dem Lancom? Ohje! Mir wäre wirklich wohler, wenn Du einen original Lancom hättest bei dem wir auf LCOS 10.42 Rel springen könnten. Ja, offiziell müsste auch LCOS 10.34 gehen, besonders bei einem Telekom-Branding-Produkt mit einem Telekom-Tarif. Aber ich traue da weder Telekom noch Lancom.

 

[diga]

Werde morgen nochmal einen aktuellen und vollständigen Trace (sowohl TCP-Dump von Telefon <-> Asterisk) sowie auf dem Lancom mit einer Problemnummer durchführen - nach all den Änderungen könnten sich da ja wieder Neuerungen ergeben haben - werde berichten.

Nur im Outbound der PJSIP mit "100rel=no" - hatte aber nur den Effekt, dass es jetzt auch bei mobilen Telekom-Nummern zu funktionieren scheint. Vereinzelte Festnetznummern (auch Telekomvertrag) aber garnicht oder nur kurz (ca. 5 Sek.) durchstellt. Andere bei Telekom oder anderen Anbietern funktionieren hingegen problemlos. Schon merkwürdig. Per ISDN-Telefon (mit der alten Anlage) ist der Anruf jedoch immer erfolgreich - werde auch diesen nochmal im Lancom tracen...

Ja, einen Beitrag in den Release-Notes von LCOS hatte ich auch zum 100rel / PRACK gefunden (glaube es war die 10.40 wo man Probleme in der Richtung mit gleichen Auswirkungen gefixt hat) - hier ein Auszug:

Es konnte vorkommen, dass der LANCOM Router im ‚183 Session Progress‘ an den Provider das Flag ‚Require: 100rel‘ verschickte, obwohl der verbundene SIP-Teilnehmer dies nicht unterstützte und auch nicht im RINGING bekanntgegeben hatte. Der SIP-Teilnehmer quittierte dies mit der Fehlermeldung ‚500 Server Internal Error‘, womit es zu einem Abbruch des Telefonates kam.

Daraufhin dann auch der Einfall es zu deaktivieren - nicht schön, doch vorerst effektiv. Leider bietet mir mein Lancom das leider nicht an - yep, immer dieses Branding...

 

[koyaanisqatsi]

Moinsen


Aushol...
Als ich qualify_frequency=0 sah, dachte ich bei mir: Deaktiviert oder Dauerfeuer?
Aber als ich mal so ein bischen nach pjsip und obiger Setting nachforschte stiess ich auf...

[Problem] - Asterisk legt nicht auf

Hallo zusammen, ich habe in Asterisk einen Telekom All IP-Anschluss konfiguriert. Klappt auch soweit alles, rein wie raus. Leider legt jedoch Asterisk das Gespräch nicht auf, wenn es von innen (also per Softphone oder DECT-Gerät) aufgelegt wird, bevor der Angerufene aufgelegt hat. Was dann...

www.ip-phone-forum.de

...und das war das Erstemal, dass so eine Setting was gebracht haben sollte.
Vielleicht hilft dies dir ja auch?