Hilfe für Grundeinstellung Asterisk/Telekom benötigt

[sonyKatze]

scheint mir veraltet zu sein

Jein. Man muss sich in Digium Asterisk für einen SIP-Channel-Driver entscheiden, chan_sip oder chan_pjsip. Letzterer (zwar die Zukunft, aber ich mag ihn nicht) erlaubt mehrere Registrierungen, wenn man in der Konfigurationsdatei pjsip.conf den Parameter max_contacts höher stellt. Eine weitere Alternative zu Digium Asterisk generell wäre FreeSWITCH.

Aber das Problem ist wie ubsyathEe schon schrieb eher die Anbindung an Telekom Deutschland. Wenn Du unbedingt willst, suche ich die Anleitung mal raus. Ich kann die nicht testen oder gar aktuell halten, weil ich kein Telekom Deutschland habe.

Aber auch ist ein Innovaphone IP111 nicht dafür gedacht außerhalb seiner Umgebung eingesetzt zu werden –, ja es geht, habe selbst ein IP222. Wenn ein Gigaset Tisch-DECT zu teuer ist, würde ich eine weitere Alternative in den Raum werfen: Einen B2BUA, von einem deutschen Hersteller, also der für Telekom Deutschland gepflegt wird. Daran registrierst Du Deine GO-Box 100 und Dein Innovaphone IP111. Das registrierst Du dann bei der Telekom Deutschland. Kandidaten wären
a) AVM FRITZ!Box wie die 7412,
b) Telekom Digitalisierungsboxen von Bintec-Elmeg (also Standard, Smart und Premium) aber auch
c) LANCOM mit All-IP-Option.
Die bekommst Du bei eBay quasi nachgeworfen. Mit einer FRITZ!Box hättest Du sogar die Möglichkeit den Strom für die GO-Box 100 zu sparen, indem Du die DECT-Mobilteile direkt in die FRITZ!Box einbuchst. Dann dürftest Du bereits nach drei vielleicht sogar nach zwei Jahren wieder im Plus sein.

Daher: Welches DSL-Modem bzw. Router hast Du aktuell? Die Frage ist auch dann wichtig, wenn Du weiter mit einem B2BUA hinter Deinem Router spielen willst. Wir müssen dann nämlich auch schauen, wie die Ports für SIP offen bleiben.

 

[Fredericderzweite]

Holla, keine email bekommen, dass Du geantwortest hast...

Nach fast einem Monat habe ich es einigermaßen geschafft, meine beiden Telefone an Asterisk anzumelden und Asterisk so zu konfigurieren, dass Gespräche darüber laufen. Allen Unkenrufen zum Trotz funktioniert es erstmal ohne größere Probleme. Sogar Interngespräche funktionieren, allerdings nur von Fon1 zu Fon2, nicht umgekehrt .

mehrere SIP Trunks der Telekom zu konfigurieren und daran beliebig viele lokale Telefone zu betreiben

das verstehe ich jetzt nicht. Wieso mehrere SIP Trunks der Telekom? Drei Nummern heisst doch nicht 3 Trunks?

Die Angaben für die Authentifizierung bei der Telekom hat mich eine Woche gekostet. In allen soweit Anleitungen/Beispielen, die ich gesehen habe, stand bei type=auth: "username=my-phonenumber". Diese Angabe funktionierte bei mir gar nicht, noch weniger, wenn ich sie einmal für FonNr1 und nochmal für FonNr2 machte. Die Credentials für die Anmeldung im Kundencenter ist das, was hier eingegeben werden muß, und zwar nur einmal.

Aktuell hänge ich an den Interngesprächen. In der extensions.conf steht

[internalcalls]
exten => 7,1,Dial(PJSIP/Gigaset)
exten => 8,1,Dial(PJSIP/IP111)

Tippe ich die 8 auf dem Gigaset, klingelt es beim IP111, rufe ich die 7 von IP111 an, kommt "Nr. unvollständig/ungültig". Auf der CLI kommt keine Meldung.
[Edit Novize: Beiträge gemäß der Forumsregeln zusammengefasst]

Welches DSL-Modem bzw. Router hast Du aktuell?

Mein DSL Modem ist das Zyxel VMG1312, als Router verwende ich die Fritzbox AVM 4040. Das Zyxel als nur-Modem ist so gut wie sein Ruf, es läuft, wird nie warm, meckert nicht, stabile Verbindungen.

chan_pjsip. Letzterer (zwar die Zukunft, aber ich mag ihn nicht) erlaubt mehrere Registrierungen, wenn man in der Konfigurationsdatei pjsip.conf den Parameter max_contacts höher stellt

Meinst du die Registrierungen bei der Telekom oder die der Telefone an Asterisk? Meine Telefone sind an Asterisk ohne FonNr angemeldet, die Zuweisung der Nummern erfolgt im Dialplan (extensions.conf) und sieht für eingehende Gespräche so aus

exten => 0891234,1,Dial(PJSIP/IP111&PJSIP/Gigaset,60)
    same => n, Hangup()
exten => 0895678,1,Dial(PJSIP/IP111&PJSIP/Gigaset,60)
    same => n, Hangup()

 

[sonyKatze]

Die Registrierungen (der Telefone) am Digium Asterisk.

 

[Fredericderzweite]

Hier meine Registrierung der Telefone

[Gigaset]
type=endpoint
transport=transport-udp
context=internalcalls
disallow=all
allow=g722
allow=alaw
auth=Giga_auth
aors=Giga

[Giga_auth]
type=auth
auth_type=userpass
password=<geheim>
username=Giga
realm=Gigaset-realm

[Giga]
type=aor
max_contacts=1
remove_existing=true

[Giga]
type=identify
endpoint=Gigaset
match=192.168.1.20

[IP111]
type=endpoint
transport=transport-udp
context=internalcalls
disallow=all
allow=g722
allow=alaw
auth=IP111_auth
aors=IP111

[IP111_auth]
type=auth
auth_type=userpass
password=<geheim>
username=IP111
realm=IP111-realm

[IP111]
type=aor
max_contacts=1
remove_existing=true

[IP111]
type=identify
endpoint=IP111
match=192.168.1.21

Die zugehörigen Einträge in der extensions.conf habe ich ja schon gepostet. Meinst du und @ubsyathEe, dass das so nicht auf Dauer funktionieren wird?

 

[sonyKatze]

Jetzt habe ich leicht den Überblick verloren. Du wolltest anfangs/irgendwann einmal mehrere Telefone über eine Registrierung laufen lassen = einen Endpoint. Also parallel klingeln lassen ohne irgendwie groß am Dialplan (Datei extensions.conf) zu basteln. Das geht in Digium Asterisk, wenn Du den Channel-Driver chan_pjsip nimmst und dort dann max_contacts erhöhst.

Aktuell hast Du einen anderen Ansatz: Einen Endpoint für jedes Endgerät. Also alles im grünen Bereich. Das wäre sogar in chan_sip gegangen.

ubsyathEes Problem (und meines) ist weniger Dein interner Aufbau als die entfernte Registrierung zu Telekom Deutschland. Das müsste ich nochmals nachlesen, aber die Telekom war mal (ist noch?) wählerisch über welche IP-Adresse Du einen Anruf aufbaust (INVITE). Wenn Du nicht über diese IP-Adresse auch eine Registrierung (REGISTER) hast, dann wurde das INVITE abgelehnt. Und all dieser „Kram“ kann sich von heute auf morgen ändern, wenn Telekom Deutschland etwas an ihrem Netz ändert.

Daher mein Tipp einen gepflegten B2BUA zu nehmen, der deutsche Verhältnisse kennt bzw. wenigstens einmal getestet hat. Das große Problem bei der Telekom ist, dass inzwischen Mobilfunk-Anrufe ungefiltert bei Dir aufschlagen, mit den wildesten SIP-Clients von WLAN-Calling bzw. VoLTE. Das hat noch nie jemand mit einem Digium Asterisk getestet. AVM, Bintec-Elmeg und LANCOM Systems kriegen die Support-Tickets irgendwann von der Telekom auf den Tisch geknallt und passen dann ihre SIP-Clients an.

Das klingt wie Unkenrufe besonders wenn es scheint, dass alles geht. Aber allein dadurch, dass die Telekom Deutschland dieses nicht-transparente Load-Balancing macht … finger weg von einem eigenen B2BUA! 1&1 macht was Ähnliches (im Detail komplett anderes), aber nur mal als Beispiel, wie komplex das ist …

 

[Fredericderzweite]

Jetzt habe ich leicht den Überblick verloren.

Das war nicht beabsichtigt. Ich hatte keine Ahnung, als ich angefangen habe ...

ubsyathEes Problem (und meines) ist weniger Dein interner Aufbau als die entfernte Registrierung zu Telekom Deutschland. Das müsste ich nochmals nachlesen, aber die Telekom war mal (ist noch?) wählerisch über welche IP-Adresse Du einen Anruf aufbaust (INVITE). Wenn Du nicht über diese IP-Adresse auch eine Registrierung (REGISTER) hast, dann wurde das INVITE abgelehnt. Und all dieser „Kram“ kann sich von heute auf morgen ändern, wenn Telekom Deutschland etwas an ihrem Netz ändert.

Wird das nicht durch die "line" option gelöst? Aktuell habe ich ja noch den Adressbereich drin stehen, aber ich versuche später, dies so zu machen wie in dem verlinkten Artikel. Gibt ja eine Menge Leute, die sich schon darüber genervt haben ...

Nachtrag: mit eingehenden Gesprächen gibt es doch Probleme. Manchmal kann ich nicht angerufen werden und muss erst mal nach draußen telefonieren. Danach gehen eingehende Anrufe wieder. Ob das nur nach Konfigurationsänderungen so ist, muss ich noch rausfinden.

Bin auch noch nicht fertig mit der Grundkonfiguration. Momentan habe ich zwei Telefone, die beide auf zwei anrufende Telefonnummern reagieren. Rausgehend habe ich nur eine ... Dazu muss ich jedes Telefon an Asterisk zweimal anmelden, aber wo trage ich die Telefonnummer ein? Beide Nummern sind bei der Telekoma angemeldet, also muss noch was in der pjsip.conf geändert werden. Aber was?

 

[sonyKatze]

Wird das nicht durch die "line" option gelöst?

Jein. Das löst eingehende Anrufe, aber auch nur dann wenn man den Digium Asterisk als Exposed-Host ins Internet stellt.

 

[gehtdoch]

Thema line-Option: Das Thema versteht man erst dann, wenn man weiß, wie die Registrierung bei Telekom / AllIP (z.B.) überhaupt funktioniert, so dass es richtig und nicht irgendwie "funktioniert". Außerdem ist sie ein wichtiges Sicherheitsfeature!

Damit der AllIP-Voice-Server weiß, welche Rufnummer eines eingehenden Calls er wohin routen muss, ist es nötig, dass für jede Rufnummer ein Register durchgeführt werden muss (kein Register vorhanden -> kein Anruf auf die Nummer möglich). Auf Asterisk übertragen heißt das: es werden 3 Trunks benötigt (falls man die standardmäßig vorhandenen 3 Nummern nutzen möchte): jeder registriert eine Nummer. Dabei wird jedesmal auf IP-Ebene dieselbe(!) Verbindung verwendet.
Wenn nun ein eingehender Call kommt, muss Asterisk irgendwie wissen, welchem Trunk der eingehende Call zuzuordnen ist. Das löst die Line-Option, indem sie bereits beim jeweiligen Register einen zufälligen (pro initialem Register) dedizierten String mitgibt. Diesen String verwendet der INVITE der Telekom beim Inbound call wieder, so dass Asterisk die Zuordnung zum Trunk vornehmen kann. Dies ist besonders dann wichtig, wenn man für unterschiedliche Nummern unterschiedliche Codecs hinterlegen muss / möchte (z.B. Fax-Nummer oder jede beliebige andere natürlich auch).

Was ich einfach immer noch nicht verstehe: warum tut man es sich an, und konfiguriert einen B2BUA vom Kaliber eines Asterisk manuell über Konfigfiles anstatt über GUIs, wo sich Experten vom Fach um die Details bereits gekümmert haben und man sich "nur" noch um das eigene Konzept kümmern muss. Das ist wahrlich schon herausfordernd genug, wenn man von VoIP-Telefonie nicht die nötige Ahnung hat bzw. man auch nicht die nötige Zeit dafür aufwenden möchte.
Natürlich ist es ok, wenn man sich das Ziel gesetzt hat, das Gleiche / Ähnliches zu können, wie die FreePBX-Spezialisten z.B.. Dann halte ich dieses Forum aber irgendwie für die falsche Anlaufadresse.

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

Das große Problem bei der Telekom ist, dass inzwischen Mobilfunk-Anrufe ungefiltert bei Dir aufschlagen, mit den wildesten SIP-Clients von WLAN-Calling bzw. VoLTE. Das hat noch nie jemand mit einem Digium Asterisk getestet.

An was denkst Du da konkret? Die Verbindung findet immer über die Voice- / Mediaserver der Telekom statt - wie soll es anders gehen? Eine direkte Peer2Peer-Verbindung ist schon aus rechtlichen Gründen nicht möglich. Außerdem möchte ein Provider ja auch verhindern, dass RTP vor dem eigentlichen Verbindungsaufbau zwischen den TN fließt. Daher wird sie da immer die Hand drauf haben.

Codecs gebe ich vor und an die muss sich auch die Telekom halten. Allein mit G711 und 722 sollte schon so gut wie jedes Gespräch funktionieren (im Notfall muss eben transcodiert werden seitens Telekom). An welche weiteren Codecs denkst Du noch, die die Mediaserver der Telekom / AllIP unterstützen? Asterisk unterstützt sehr viele Codecs.

 

[sonyKatze]

Einfach die Release-Notes von LANCOM Systems (seit Jahren) mitverfolgen und … staunen. Rest verstehe ich nicht. Ich hatte hier schon eine Verbindung mit 3GPP-EVS. Den Tipp mit FreePBX kann man lieber sagen bzw. an anderen Orten diskutieren … Frederic, willst Du wirklich, wirklich trotz der Gegenargumente einen eigenen Software-basierten B2BUA aufziehen? Willst Du wirklich anstatt Sangoma FreePBX oder FreeSWITCH direkt auf Digium Asterisk setzen? Dann schaue ich mal, ob ich eine Anleitung finde. Ein „Ja“ reicht.

 

[gehtdoch]

Dass es von Zeit zu Zeit immer mal wieder zu Problemen kommt ist bei lebenden Systemen völlig normal. Seien es Neuerungen oder Bugs (davon gibt es auch jede Menge). Als Eigenbetreiber eines beliebigen Voiceservers muss man sich dessen bewusst sein und in der Lage sein, selbst Probleme zu analysieren und im Idealfall auch zu fixen. Dein Hinweis ist also absolut berechtigt (-> heute schon an morgen denken).
Ist aber kein typisches Phänomen der Telekom oder gar deutsches Phänomen sondern ein weltweites (die kochen alle überall nur mit dem jeweils eigenen Wasser).

EVS habe ich bisher noch nie bewusst gesehen (im Sinne von: es gab Probleme damit) und kann aus meiner Sicht nur dann eines sein, wenn irgendeiner EVS-only fährt. Wenn derjenige dann Probleme bekommt, hat er sie wohl (-> eigene Dummheit). Wer meint, EVS mit Asterisk zu brauchen, wird hier fündig.

Lancom erwähnt in den Releasenotes folgendes Phänomen:
"Bei Telekom-VoIP-Anschlüssen konnte es vorkommen, dass bei einem per SIP-Client initiierten Festnetz-Anruf kein „Klingeln“-Signal auf der Leitung ausgegeben wurde"

Korrekt. War ca. ganz grob Ende vorletzten / Anfang letzten Jahres (meine Patche dazu stammen aus Anfang 2019).

Lancom weiter:
"da der Provider ein „Ringing“ ohne Session Description Protocol (SDP) sendete. In der Folge verlief der Rufaufbau bis zur Rufannahme ohne Ton-Signalisierung."

Ein 180 Ringing ohne SDP ist der Normalfall! Habe noch nie was anderes gesehen (bei der Telekom) und wäre hier auch nie ein Problem gewesen!

Aus meinen Traces ergaben sich die folgenden zwei Problemfälle:

1. 183 Session Progress ohne SDP (ist für mich ein Bug): kein Ringback zu hören bei ausgehendem Call, weil kein erwartetes Inband-Ringing erfolgte. Das manchmal danach noch korrekte 180 Ringing folgende Paket hat auch nichts mehr gebracht. Patch: Mache aus 183 ohne SDP 180 Ringing (welches dem Telefon einfach nur sagt: erzeuge selbst ein Ringback-Signal).
2. 180 Ringing mit SDP (ist für mich auch ein Bug - ich kenne 180 nur ohne SDP - alles andere macht für mich keinen Sinn): Auch kein Ringing zu hören. Patch: mache 183 Session Progress mit SDP draus.

An der Stelle ist sogar noch die große Frage, ob das in beiden Fällen überhaupt ein Asterisk-Problem war / ist, oder ob es ein Problem des dahinterliegenden Telefons (hier ein C610 IP) ist, das sich einmal eingeschossen auf eine Ringing-Variante nicht mehr "umpolen" ließ.
Wäre interessant, ob man die Patches heute überhaupt noch braucht. Aber sie tun auch nicht weh hier bisher. Daher alles gut.

 

[sonyKatze]

Du hast meine Argumente nicht verstanden und zeigst auch nicht, dass Du sie verstehen willst. Warum sollte ich es Dir erklären? Wie Du richtig schreibst, kann mit der Telekom Deutschland jeden Tag ein neuer Software-Bug auftauchen. Das liegt zum Einen daran, dass die teilweise wilde Dinge machen (Thema: Load-Balancing, MediaSec, …), immer weiter auf ein IP-Multimedia-System (IMS) umstellen (Thema: SDP und RTP kommt direkt an) und dass dort bei der Telekom niemand sitzt, der versucht mit bestehenden VoIP/SIP-Implementierungen kompatibel zu sein. Man gibt Schnittstellen-Beschreibungen raus und soll dann in deren Test-Center kommen (Thema: Hol-Bring-Schuld). Aber man kündigt kleine Änderungen nicht wirklich an. Entsprechend müsste man mit einem nicht-qualifizierten Produkt laufend alles testen, ob es noch geht. Und das bei einem Standard, den es bereits seit zwanzig Jahren gibt – Dir können die wildesten Dinge passieren.

Andere VoIP/SIP-Provider (dus.net, Easybell, Sipgate, …) bemühen sich wenigstens phasenweise kompatibel zu sein. Für all das ist Digium Asterisk (aber auch FreeSWITCH) nicht wirklich ausgelegt. Nur als Beispiel: Du wirst in Zukunft während einem Gespräch die wildesten Audio-Codec-Aushandlungen sehen, innerhalb des Codecs und über Codecs hinweg (Thema: EVS, AMR-WB, AMR, GSM-EFR, GSM, GSM Half-Rate). Daher ist das Argument mit „weltweit“ völlig falsch. Es geht darum einen Hersteller zu finden, der für Dich die Änderungen bei der Telekom Deutschland mitverfolgt – der die deutschen Verhältnisse kennt. Das wäre ein Anfang, weil man sonst alles selbst, laufend prüfen muss. Nur als Beispiel: Selbst Snom ist (seit Jahren) nicht mit 1&1 kompatibel – man ist maximal (!) nur in 50% der Fälle erreichbar. Das zeigt, dass ein lokaler Hersteller kein Garant dafür ist, die „Verhältnisse vor Ort“ aufzusaugen bzw. sich zu kümmern. Aber es wäre ein Anfang. Ich bin kein Freund von diesen in Hardware gegossenen Übergangsboxen, weil ich so auf den Willen des Herstellers angewiesen bin. Aber bei AVM, Bintec-Elmeg und LANCOM Systems besteht wenigstens (indirekt) der Wille mit der Telekom Deutschland kompatibel zu sein. Daher kann man sich überlegen, deren B2BUA mal anzuschauen. Preislich sind das keine 80€ gebraucht. Und weil alle drei inzwischen automatische Software-Updates bereitstellen, sind das tatsächlich die schon-eher-auch-in-Zukunft-sorglos-Pakete, die viele erwarten (aber mit VoIP/SIP nicht mehr bekommen).

Wenn Du eine aktuelle Anleitung für Digium Asterisk mit Telekom Deutschland hast, nur her damit. Ich müsste erst lange suchen. Daher versuche ich bei Frederic nachzubohren, ob er verstanden hat, dass er sich eine (potentielle) Dauerbaustelle schafft. Auch lernen tut man kaum. Ob man jetzt ein Digium Asterisk, Sangoma FreePBX oder LANCOM meistert, hilft einem auf lange Sicht wenig.

 

[gehtdoch]

Irgendwie klingt das, was Du da schreibst, teilweise nach FUD.

Codecaushandlungen während des Gesprächs sind ja grundsätzlich nichts Neues - wenn auch stand heute eher selten.
Was Du ansprichst ist auch keine Telekomerfindung sondern kann Dir woanders grundsätzlich genauso über den Weg laufen.

Willst Du zwischen den Zeilen transportieren, dass die Telekom transcoding einstellen will? Woher weißt Du das?
Auf der anderen Seite: was spricht dagegen, neue Codecs einzuführen? Absolut nichts. Sicherlich noch nicht fertig - aber ein Anfang - schon vor Jahren gemacht. Bisher vermisse ich da nichts. Was morgen kommt wird man morgen sehen. IT ist nicht statisch.

Wir nutzen Asterisk mittlerweile massiv seit Monaten beruflich im Homeoffice. Da geht alles drüber und im Vergleich zu so manch anderer Lösung, die mir da so unterkommt bei den Kollegen, absolut problemfrei - und das incl. MediaSec(!) - ein Lob an die Telekom! Nicht wenige Calls gehen dabei >> 3h (teilweise bis zu 7h - ohne jede Unterbrechung oder sonstiges Zucken). Da ich über viele Kanäle erreichbar bin, würde ich es auch ziemlich schnell mitbekommen, wenn ein Kanal (hier: Telefonie) nicht funktionieren würde. Das ist aber gerade derjenige, der mit Abstand am Besten von allen funktioniert (100% Verfügbarkeit bisher - da kommt kein anderer dran).

Was die vollständige Konfig für die Telekom / AllIP hinsichtlich Asterisk 16 / pjsip (und FreePBX) angeht: die habe ich hier im Forum geschrieben. Einfach danach suchen. Die läuft bei mir exakt so absolut schmerzfrei.

Was das Betriebskonzept angeht mit drei IPs, welche jeweils vollständig getrennt voneinander betrieben werden (ja, das macht durchaus Sinn hinsichtlich Ausfallsicherheit und Lastverteilung - da scheinen mir komplett getrennte, jeweils vollständig autark operierende Cluster dahinter zu hängen): kannst Du über eine eigene rpz realisieren (via Bind), die Du selbst mit einem regelmäßigen Script befüllst und Asterisk bedient sich unwissend an der RPZ. Schon hat Asterisk kein Problem mehr. Wenn ein Server verschwindet, sorgt das Script dafür, dass die Änderung erst dann "publiziert" wird, wenn Asterisk grad mal keinen Call über einen Telekomtrunk hat und macht dann einen ReRegister. Nicht unbedingt intuitiv, aber funktioniert (hatte ich in vielen Jahren nie automatisch gebraucht - nur einmal habe ich manuell einen rausgenommen, weil der gesponnen hat).

Unabhängig davon kann ich mich nur wiederholen und auch Dir an dieser Stelle zustimmen: wer einen eigenen Server betreibt, muss sich grundsätzlich auch um dessen ordentliche Lauffähigkeit selbst kümmern (da gehört noch weit mehr dazu, als die reine SIP / RTP Protokollebene). Man hat dann nur sich selbst, um jedes beliebig auftretende Problem zu analysieren und zu lösen. Das bedarf einer Menge KnowHow auf verschiedensten Ebenen - verbunden mit zeitlichem Aufwand. Das muss jeder für sich selbst entscheiden, ob er das machen möchte oder nicht oder ob ihm eine Kauflösung lieber ist (die ja auch oft nicht funktioniert und wo man dann davon abhängig ist, dass es hoffentlich mal einer irgendwann fixt). Ich persönlich bevorzuge die Variante, wo ich weitgehend unabhängig bin von einem Hersteller und Probleme selber bis auf die relevante Sourcecode-Zeile runtertracen kann und dann auch adäquat fixen kann. Schon allein aus Sicherheitsgründen kommt mir ganz sicher keine Kaufbox ins Haus.

 

[Fredericderzweite]

So, nach längerer Zeit des Ausprobierens und Testen melde ich mich zurück. Die Diskussion ist ja etwas ins Grundsätzliche abgeschweift....

Was ich einfach immer noch nicht verstehe: warum tut man es sich an, und konfiguriert einen B2BUA vom Kaliber eines Asterisk manuell über Konfigfiles anstatt über GUIs, wo sich Experten vom Fach um die Details bereits gekümmert haben und man sich "nur" noch um das eigene Konzept kümmern muss

Ich hatte mir zuerst eine FreePBX installiert und nichts, absolut nichts verstanden. Das entsteht, wenn Autisten die Anleitungen schreiben (das soll nicht gegen Autisten sein sondern Leute, die meinen, Fach-Denglisch ist ausreichend verständlich für Laien). Jetzt ist die Situation eine andere und ich werde es noch einmal probieren.

Grundsätzlich läuft übrigens alles, keine Gesprächsabbrüche, keine Störungen. Ich wäre somit ganz zufrieden , ABER:

Jeden Tag muss ich erst mal irgend eine Telefonnummer anklingeln. Wenn ich das nicht mache, kommen keine Gespräche an. Der Anrufer hat eine komplett tote Leitung. Nach diesem anklingeln (muss keine Gesprächsverbindung sein), kommen alle Gespräche problemlos an. Bis zum nächsten Tag dann. Raustelefonieren geht immer ohne Probleme.

Weder im Log noch auf der Cli wird in dem Fall irgend was angezeigt, deshalb vermute ich, dass die Telekom die Gespräche gar nicht an mich weiterleitet. Hat jemand eine Idee?

 

[Meester Proper]

Hört sich danach an, dass das NAT Binding im Router in den Timeout läuft.
Erfolgt die Registrierung über UDP oder TCP?
Werden Keepalives gesendet?

 

[Fredericderzweite]

Hört sich danach an, dass das NAT Binding im Router in den Timeout läuft

Auch die Suche im Internet nach 'NAT binding' brachte keinen Erfolg. Ich rate mal, dass es bedeutet, der Router könne den eingehenden Anruf keiner IP Adresse zuordnen? Dann wäre es ein Problem in den Routereinstellungen?

Erfolgt die Registrierung über UDP oder TCP?

UDP

Werden Keepalives gesendet?

werden die nicht verwendet, um Gesprächsunterbrechungen zu vermeiden? Tut mir Leid, bin Anfänger und verstehe so manches noch nicht

 

[gehtdoch]

@Fredericderzweite
Teilweise auf die Aussage von Meester Proper bezogen:

Keepalives = qualify in Asterisk

Aus Deinen Fragen entnehme ich:
Du solltest Dich dringend über NAT aufschlauen. Sobald Du NAT - und damit die Rolle von Firewalls / Portfilter - in beide Richtungen verstanden hast und wie sie ticken, solltest Du als nächstes das SIP-Protokoll inkl. SDP verstehen lernen. Lerne, wie man SIP tracen kann. Wie man die Traces mit Wireshark auswertet. Das erleichtert die Sache (insbesondere das Lernen) ungemein. Wenigstens die Basics. Außerdem hilft es ungemein bei der Fehlersuche.
Als drittes solltest Du dann lernen, was es bedeutet, SIP und NAT zu verbinden. Falls Du an dieser Stelle zur Erkenntnis kommen solltest, dass man SIP und NAT nicht wirklich haben will, kannst Du Dir gratulieren. Dann hast Du es final verstanden (ist absolut nicht böse gemeint).

 

[sonyKatze]

Wie soll man etwas lernen, wenn man Probleme hat, den Start-Punkt für die eigenen Recherche zu finden … nochmal zurück zu Deiner FRITZ!Box 4040. In der kannst Du IP-Telefone anlegen. Du legst ein IP-Telefon für jedes Deiner Tisch-Telefone an. Damit verbindest Du Deine Innovaphone IP111. Die Mini-Telefon-Anlage im Innovaphone selbst nutzt Du nicht.

„NAT binding“ … der Router könne den eingehenden Anruf keiner IP Adresse zuordnen?

Fasst. Du hast in Deinem Router eine Firewall, die zwanghaft versucht alle Ports geschlossen zu halten. Wenn eine IP-Verbindung keinen Datenverkehr aufweist, dann schließt die Firewall den Port. Die Zeitspanne dafür – im Englischen „Session Timeout“, „Binding“ bzw. „Aging“ genannt – ist vergleichsweise kurz. Bei einer FRITZ!Box nur fünf Minuten, also 300 Sekunden. Die Zeitspanne kannst Du selbst ermitteln, z.B. über
$ turnutils_natdiscovery -t -T 295 stun.antisip.com
Erhältst Du auf „Response 1“ ein „STUN receive timeout..“, sind 295 Sekunden zu lang. Erhältst Du „Response 2“, hast Du einen Wert innerhalb Deiner Zeitspanne. Was dieses Tool genau macht, steht in RFC 5780 Abschnitt 4.6. Dort stehen auch noch mehr Hintergründe. Muss man nicht lesen. Wenn noch Fragen, einfach fragen. Wie schwer das Thema selbst für Fachleute-unter-sich ist, siehst Du daran, dass ich hier von Firewall rede, die Ursache aber als „NAT-Binding“ bzw. „NAT-[Session]-Timeout“ bezeichnet wird. Und NAT ist etwas, was ich eigentlich nur in IPv4 habe. Aber dieses Problem besteht auch ohne NAT in IPv6.

UDP

TCP hat traditionell längere Zeitspannen.
Weil die Telekom Deutschland nicht nur SIP über UDP sondern auch TCP anbietet, wäre daher eine Herangehensweise in Digium Asterisk den Transport von UDP auf TCP zu ändern.

Keep-Alives

Damit dieses Zeitfenster sich nicht schließt, ist ein Trick, auf der IP-Verbindung (für die VoIP/SIP-Signalisierung) immer mal wieder Datenverkehr zu erzeugen. So schließt die Firewall diese IP-Verbindung nicht (solange bis wieder zu lange Ruhe ist). Und jetzt wird es kompliziert. Offiziell bietet Digium Asterisk für Provider-Registrierungen (über UDP) kein Keep-Alive, weder im alten Channel-Treiber chan_sip noch im aktuellen chan_pjsip. Warum auch immer†. Für uns Normalos mit Firewall, NAT und Privat-Anschlüssen bedeutet das:

A) lege im Router eine Port-Freigabe an.
siehe Konfigurationsdatei pjsip.conf Abschnitt type=transport Parameter bind. Steht dort kein Port, bist Du auf 5060.
Das hat den Nachteil, dass alle eingehenden Pakete auf Port 5060 bei Deinem Digium Asterisk landen, also auch solche die nicht von der Telekom Deutschland stammen. Das sind dann VoIP-/Port-Scanner, die versuchen bei Dir einzubrechen, um über Dich teure Telefonate zu führen. Bei einem korrekt eingestellten Digium Asterisk nicht das Problem …

oder
B) wechsele in Digium Asterisk von UDP auf TCP; Abschnitt type=transport auf transport=tcp.
Dann greift im Abschnitt type=global der Parameter keep_alive_interval=295. Steht das dort nicht, bist Du nicht auf 295 sondern 90 Sekunden. In dem Punkt ist sogar die Dokumentation in der Beispiel-Datei pjsip.conf.sample falsch. Das zeigt erneut, wie fragil dieses eigentlich basale Thema Erreichbarkeit in Digium Asterisk bzw. VoIP/SIP im Allgemeinen ist. Egal. So verschickt Digium Asterisk alle 295 Sekunden als Keep-Alive ein Double-CRLF-Refresh.

oder
C) lege ein type=aor mit qualify_frequency=295 und contact an. Beim contact gibst Du als Wert dasselbe wie bei registration/client_uri an. Diesen AOR referenzierst Du aus einem type=endpoint heraus. Diesen Endpoint wiederum referenziert Du aus dem type=registration heraus. Damit dieser Endpoint überhaupt geladen wird, musst Du noch zusätzlich im type=registration den Parameter line=yes setzen.
So verschickt Digium Asterisk alle 295 Sekunden (minus qualify_timeout) als Keep-Alive eine SIP-OPTION.

Das waren Deine drei Alternativen. Theoretisch könntest Du als Alternative D stattdessen auch einen Router/Firewall holen, welche Dir erlaubt diese Zeitspannen einzustellen. Mehr dazu in diesem Thread … als NAT-Bindung nimmst Du den Wert des Expires, welches die Telekom Deutschland Dir in der Antwort auf das SIP-REGISTER geschickt hat. Diese Alternative lässt sich auch mit Alternative B kombinieren. Und wenn Du mit TCP statt einem Double-CRLF-Refresh, also keep_alive_interval=0 lieber TCP-Keep-Alives nutzen willst:
$ sudo sysctl -w net.ipv4.tcp_keepalive_time=295

Das wäre die sauberste Alternative, also im Digium Asterisk von UDP auf TCP wechseln, das TCP-Keep-Alive des Host-Systems des Digium Asterisk auf Deine lokale NAT-Session-Timeout stellen. Und nie mehr Probleme haben.

† Wenn ich ehrlich bin, ist das bei UDP auch gar nicht nötig, denn Du kannst bei UDP parallel dafür ein Skript laufen lassen …

Die Diskussion ist ja etwas ins Grundsätzliche abgeschweift.

Wir können Dir nicht einfach nur Deine Fragen beantworten. Wir haben auch eine Verantwortung Dir gegenüber. Auch wenn viele Anleitungen im Netz „einfach“ aussehen, im Detail ist es dann doch kompliziert bzw. – wie Du gemerkt hast – sind die Anleitungen unvollständig bzw. selten nachvollziehbar. Ich bin mir bei Dir überhaupt nicht sicher, ob Du weißt, was Du Dir da antust. Daher die Nachfragen, ob Du nicht
A) auf einer höheren Abstraktion (Sangoma FreePBX) oder
B) mit einer moderneren Lösung (FreeSWITCH) oder
C) mit einer Übergangsbox dazwischen (AVM FRITZ!Box)
besser aufgehoben bist. Ich empfehle Alternative C, siehe auch Post #6. Und wenn die Alternative nicht genommen wird – was vollkommen OK ist –, erwarte ich aber Nachfragen oder Begründungen. Wenn ich sehe, dass Du es verstanden hast, darfst Du gerne machen was Du willst.

Willst Du zwischen den Zeilen transportieren …

Du hast meine Argumente nicht verstanden und zeigst auch nicht, dass Du sie verstehen willst.
Für alle Anderen: Die Deutsche Telekom schert sich nicht um Digium Asterisk, Sangoma FreePBX oder FreeSWITCH. Im Gegensatz zu vielen anderen VoIP/SIP-Anbietern. Entsprechend kann von heute auf morgen einiges, manches (oder wenn Du Glück hast!) gar nichts funktionieren – von heute auf morgen. Folglich müsste man jeden Tag wenigstens die wichtigsten Anruf-Szenarien durchspielen – also testen. Manche Tests erfordern Wissen, was alles schief sein kann – also Fachwissen. Wenn dann etwas kaputt ist, kannst Du niemanden bei der Telekom Deutschland anrufen. Du musst es selbst fixen. Ich bin kein großer Fan von diesen Übergangsboxen bzw. Kauf-Boxen, weil das Black-Boxes sind, die ich nicht selbst ändern kann. Aber, aber, bei einem VoIP/SIP-Provider wie der Deutschen Telekom, die sich nicht um Digium Asterisk schert sind solche Boxen pures Gold wert. Ich als Normalo kann zwar auch niemanden bei AVM, Bintec-Elmeg oder Lancom erreichen, aber diese drei Hersteller können es sich nicht erlauben, nicht mit der Telekom Deutschland kompatibel zu sein. Und noch was: Vieles ist bereits kaputt, denn die Telekom ist ein IMS basierter VoIP/SIP-Anbieter. Damit ist der im Grund 20 Jahre alte Digium Asterisk nie getestet worden.

Was die vollständige Konfig für die Telekom / AllIP hinsichtlich Asterisk 16 / pjsip (und FreePBX) angeht: die habe ich hier im Forum geschrieben. Einfach danach suchen.

Hier im Forum kann man direkt verlinken. Oben rechts bei jedem Post einen Kontext- bzw. Rechts-Klick auf die Post-Nummer z.B. #1. Kopieren. Dann auf das Symbol „Link einfügen“ gehen. Einfügen. Warum Du das nicht einfach machst? Ich vermute mal Du meinst Post #5 …

 

[Fredericderzweite]

Wie soll man etwas lernen, wenn man Probleme hat, den Start-Punkt für die eigenen Recherche zu finden …

Danke

nochmal zurück zu Deiner FRITZ!Box 4040. In der kannst Du IP-Telefone anlegen. Du legst ein IP-Telefon für jedes Deiner Tisch-Telefone an. Damit verbindest Du Deine Innovaphone IP111. Die Mini-Telefon-Anlage im Innovaphone selbst nutzt Du nicht.

"Unterstützung für FRITZ!App Fon in der FRITZ!Box aktivieren". Ich machs ungern schwierig, aber leider habe ich das FritzOS runtergeschmissen und durch OpenWRT ersetzt. Also habe ich keine PBX auf dem Router. Das sollte ja dann Asterisk übernehmen.

Damit dieses Zeitfenster sich nicht schließt, ist ein Trick, auf der IP-Verbindung (für die VoIP/SIP-Signalisierung) immer mal wieder Datenverkehr zu erzeugen.

Davon hatte ich schon mal gelesen, ist aber im Glück, dass es "funktionierte", in Vergessenheit geraten.

Und wenn die Alternative nicht genommen wird – was vollkommen OK ist –, erwarte ich aber Nachfragen oder Begründungen

Ich möchte mit dem anfangen, was an Hardware verfügbar ist. D.h. Lösung A auf einem Raspi, gibt es ja als Komplettinstallation inkl. OS.
Muss jetzt los, melde mich morgen nochmal. Trotzdem, ein herzliches Danke. Ich bin mir bewusst, dass ich eine Gradwanderung beschreite zwischen berechtigten Fragen und und sturem "aber ich will das so machen". Gebe mir Mühe, möglichst mein Wissen zwischen den Posts zu erweitern.

 

[Fredericderzweite]

wechsele ... auf transport=tcp.
Dann greift im Abschnitt type=global der Parameter keep_alive_interval=295. Steht das dort nicht, bist Du nicht auf 295 sondern 90 Sekunden

Transport ist auf TCP umgestellt. Den "keep_alive_interval" habe ich weggelassen ----> pjsip show settings ergibt 90. Dann den Eintrag wie emfohlen gemacht -->295s.
Jetzt müsste ich mit wireshark hantieren um zu sehen, ob der Asterisk Server was schickt. Weiß nicht, ob ich das hinbekomme, aber ich sehe es ja morgen .

Im Übrigen passen deine Ausführungen auf eine weitere Beobachtung: Ich hatte die Gigasset-Box vom Server abgeklemmt und dessen PBX verwendet. Das Tischtelefon blieb über Asterisk am Netz. Und es funktionieren beide Telefone ohne diese Abrüche. Vermutlich sendet die Gigabox das Päckchen, um den Port 5060 offen zu halten.

Also leite ich das Gigaset wieder auf den Asterisk Server und schaue, ob es morgen noch funktioniert.

Nachtrag:
ich habe eine Nummer auf transport=tcp gesetzt, die andere auf transport=udp. Die Nummer mit TCP kann weder raustelefonieren noch angerufen werden (Einstellungen an den Telefonen nicht verändert).

Auf dem Gigaset habe ich die zusätzliche Möglichkeit, tcp, udp oder automatisch auszuwählen. Egal was in der pjsip.conf steht, das Telefon funktioniert nur auf udp oder automatisch. Anscheinend spielt es keine Rolle, was in der Konfiguration des Asterisk Server drinsteht?????

 

[sonyKatze]

Wenn die Telefonanlage direkt im Router ist, hat die Telefonanlage auch die Firewall komplett unter Kontrolle. Das macht diese B2BUA mit Router und PPPoE-Client von AVM, Bintec-Elmeg und Lancom so interessant: Firewall und Telefonanlage sind eins und NAT ist egal. Übrigens kann das auch Dein Innovaphone. Deswegen hat es einen PPPoE-Client – aber die Implementierung würde ich für Telekom Deutschland nicht nehmen.

Ich möchte mit dem anfangen, was an Hardware verfügbar ist.

Recyceln und Ressourcen sparen ist eine tolle Idee. Allerdings machst Du Dich dann selbst zu einem Software-Maintainer. Du installiert die Software nicht nur einmal. Stattdessen musst Du ständig Updates einpflegen. Und danach musst Du jedesmal alles testen. Unser Nutzer gehtdoch musste aus neueren Versionen von Digium Asterisk schon einzelne Änderungen wieder zurück-patchen. Lange Rede kurzer Sinn: Durch diese Sparsamkeit auf der Hardware-Seite erkaufst Du Dir nimmer endende Arbeit auf der Software-Seite. Eine Dauerbaustelle. Du hast ein neues Hobby. Wenn Dir das bewusst ist, alles OK. Willkommen im Club.

Gebe mir Mühe, möglichst mein Wissen zwischen den Posts zu erweitern.

Musst Du nicht. Im Internet findet sich soviel alter und inzwischen falscher Kram. Einfach posten bzw. fragen. Niemand ist gezwungen zu antworten. Und wenn jemand schneller mit der Antwort ist, als Du mit der Recherche bist, hast wenigstens Du Zeit gespart (und viele Fragen haben auch passive Leser, die in den nächsten Jahren hier vorbei stolpern).

ich habe eine Nummer auf transport=tcp gesetzt

Du „musst“ lediglich den Transport für die Registrierung auf TCP setzen. Alles im Heimnetz kann auf UDP bleiben, weil Du innerhalb Deines Heimnetz keine Firewall hast.

Transport ist auf TCP umgestellt

Wenn Du OpenWRT als Router und SIP-over-TCP nutzt, brauchst Du im Digium Asterisk kein Keep-Alive …