Discussion:
Das "nach 15 Minuten Abbbruch"-Problem
(zu alt für eine Antwort)
Holger Marzen
2017-06-20 19:18:55 UTC
Permalink
Asterisk 11 auf Debian 8 hinter NAT-Router
chan_sip

Ich dachte, ich wäre verschont geblieben, aber das war Zufall. Von
Telekom nach Telekom brechen keine Gespräche ab.

Aber von Telekom nach 1&1 nach etwas unter 15 Minuten.
Ruft der 1&1-Teilnehmer mich auf Telekom an, hält das Gespräch.

session-timers=reject

hilft leider nichts. Ich habe auch im Web nach stundenlangem Stöbern
keine Lösung gefunden. Das Problem haben viele, eine Lösung scheint es
nicht zu geben. Ideen?
Andreas Hartmann
2017-06-21 02:52:10 UTC
Permalink
Post by Holger Marzen
Asterisk 11 auf Debian 8 hinter NAT-Router
chan_sip
Ich dachte, ich wäre verschont geblieben, aber das war Zufall. Von
Telekom nach Telekom brechen keine Gespräche ab.
Aber von Telekom nach 1&1 nach etwas unter 15 Minuten.
Ruft der 1&1-Teilnehmer mich auf Telekom an, hält das Gespräch.
session-timers=reject
hilft leider nichts. Ich habe auch im Web nach stundenlangem Stöbern
keine Lösung gefunden. Das Problem haben viele, eine Lösung scheint es
nicht zu geben. Ideen?
Wie ich an anderer Stelle schon geschrieben habe: Die Lösung heißt pjsip.


Gruß,
Andreas
Holger Marzen
2017-06-21 06:39:36 UTC
Permalink
Post by Andreas Hartmann
Wie ich an anderer Stelle schon geschrieben habe: Die Lösung heißt pjsip.
Ich nehme an, es ist die Gegenstelle, die auf UPDATE besteht, aber nur
REINVITE vom Asterisk bekommt und dann ihren Timer runterzählt und dann
das Gespräch beendet, oder?

Welche Version von asterisk hast Du denn, und was musstest Du tun, um
pjsip zu aktivieren?

Ich plane, zunächst eine zusätzliche VM mit Asterisk aufzusetzen, um mal
einen Link mit pjsip zu betreiben, ohne gleich alles umzustellen.

Hinweise, wie man eine chan_sip-Konfiguration in eine
pjsip-Konfiguration überführt, habe ich schon gefunden.
Andreas Hartmann
2017-06-21 14:52:08 UTC
Permalink
Post by Holger Marzen
Post by Andreas Hartmann
Wie ich an anderer Stelle schon geschrieben habe: Die Lösung heißt pjsip.
Ich nehme an, es ist die Gegenstelle, die auf UPDATE besteht, aber nur
REINVITE vom Asterisk bekommt und dann ihren Timer runterzählt und dann
das Gespräch beendet, oder?
Details kann ich Dir nicht sagen. Der ReInivite geht jedenfalls
*scheinbar* problemlos bei Dir durch (wird ja von der Telekom aus
getriggert), aber die schieben es wohl nicht sauber zum Peer rüber - wie
auch immer - die Gegenseite habe ich nie getraced - kann also nichts
Belastbares dazu sagen. Fakt ist, dass es via UPDATE geht - was chan_sip
nicht beherrscht.
Post by Holger Marzen
Welche Version von asterisk hast Du denn, und was musstest Du tun, um
pjsip zu aktivieren?
13.16.x - darunter für pjsip auf keinen Fall - bis zu dieser Version
gibt es einige gefixte Probleme, die im Speziellen bei der komplexen
Infrastruktur der Telekom auftreten. Betrifft u.a. das DNS-SRV-Handling
(wichtig für die Hochverfügbarkeit bei der Telekom) sowie die Option
match (wobei ich von der mittlerweile abrate - besser ist line=yes und
enpoint=Extension bzw. beteffender Trunkname).
Post by Holger Marzen
Ich plane, zunächst eine zusätzliche VM mit Asterisk aufzusetzen, um mal
einen Link mit pjsip zu betreiben, ohne gleich alles umzustellen.
Du kannst die selbe Installation nehmen und parallel trunks / extensions
mit pjsip bereitstellen. pjsip bindest Du dann eben auf den Port 5061
z.B. - oder jeden beliebigen anderen statt 5060/chan_sip. Musst eben
firewalltechnisch nachziehen im sip connection tracking und ihm
mitteilen, welche Ports zu überwachen sind. die chan_sip Zugänge, die Du
nicht mehr benötigst, kannst Du deaktivieren (zumindest bei FreePBX).

Aber natürlich geht auch eine weitere VM parallel zum Testen. Man muss
dann eben sehen, wie man die beiden parallel betreibt.
Post by Holger Marzen
Hinweise, wie man eine chan_sip-Konfiguration in eine
pjsip-Konfiguration überführt, habe ich schon gefunden.
Mit FreePBX geht das auf Knopfdruck - zumindest was das Grunsdsätzliche
angeht. Es gibt aber diverse Stolperfallen (ganz speziell bei der
Telekom, die eine ziemlich komplexe Infrastruktur fährt), die man
berücksichtigen muss, sonst hat man ziemlich wenig Spaß.


Gruß,
Andreas
Holger Marzen
2017-06-21 19:51:01 UTC
Permalink
Post by Andreas Hartmann
Post by Holger Marzen
Post by Andreas Hartmann
Wie ich an anderer Stelle schon geschrieben habe: Die Lösung heißt pjsip.
Ich nehme an, es ist die Gegenstelle, die auf UPDATE besteht, aber nur
REINVITE vom Asterisk bekommt und dann ihren Timer runterzählt und dann
das Gespräch beendet, oder?
Details kann ich Dir nicht sagen. Der ReInivite geht jedenfalls
*scheinbar* problemlos bei Dir durch (wird ja von der Telekom aus
getriggert), aber die schieben es wohl nicht sauber zum Peer rüber - wie
auch immer - die Gegenseite habe ich nie getraced - kann also nichts
Belastbares dazu sagen. Fakt ist, dass es via UPDATE geht - was chan_sip
nicht beherrscht.
Ich werde vor dem Test eines neuen Asterisk mal einen vorgeschalteten
siproxd ausprobieren. Angeblich ist der da, um viele Probleme zu
beheben, und er kann auch UPDATE.
Holger Marzen
2017-06-22 18:23:08 UTC
Permalink
Post by Holger Marzen
Post by Andreas Hartmann
Post by Holger Marzen
Post by Andreas Hartmann
Wie ich an anderer Stelle schon geschrieben habe: Die Lösung heißt pjsip.
Ich nehme an, es ist die Gegenstelle, die auf UPDATE besteht, aber nur
REINVITE vom Asterisk bekommt und dann ihren Timer runterzählt und dann
das Gespräch beendet, oder?
Details kann ich Dir nicht sagen. Der ReInivite geht jedenfalls
*scheinbar* problemlos bei Dir durch (wird ja von der Telekom aus
getriggert), aber die schieben es wohl nicht sauber zum Peer rüber - wie
auch immer - die Gegenseite habe ich nie getraced - kann also nichts
Belastbares dazu sagen. Fakt ist, dass es via UPDATE geht - was chan_sip
nicht beherrscht.
Ich werde vor dem Test eines neuen Asterisk mal einen vorgeschalteten
siproxd ausprobieren. Angeblich ist der da, um viele Probleme zu
beheben, und er kann auch UPDATE.
Das war nicht erfolgreich. Ich habe den nicht so einfach vorschalten
können, wie ich dachte.

Ich habe jetzt Debian8 auf Debian9 upgedatet, das bringt Asterisk
13.14.1 mit. Nicht ganz so hoch, wie Du empfohlen hast, aber er bringt
pjsip mit. D.h. ich werde damit mal einen Trunk anlegen.
Andreas Hartmann
2017-06-22 19:42:13 UTC
Permalink
Post by Holger Marzen
Post by Holger Marzen
Post by Andreas Hartmann
Post by Holger Marzen
Post by Andreas Hartmann
Wie ich an anderer Stelle schon geschrieben habe: Die Lösung heißt pjsip.
Ich nehme an, es ist die Gegenstelle, die auf UPDATE besteht, aber nur
REINVITE vom Asterisk bekommt und dann ihren Timer runterzählt und dann
das Gespräch beendet, oder?
Details kann ich Dir nicht sagen. Der ReInivite geht jedenfalls
*scheinbar* problemlos bei Dir durch (wird ja von der Telekom aus
getriggert), aber die schieben es wohl nicht sauber zum Peer rüber - wie
auch immer - die Gegenseite habe ich nie getraced - kann also nichts
Belastbares dazu sagen. Fakt ist, dass es via UPDATE geht - was chan_sip
nicht beherrscht.
Ich werde vor dem Test eines neuen Asterisk mal einen vorgeschalteten
siproxd ausprobieren. Angeblich ist der da, um viele Probleme zu
beheben, und er kann auch UPDATE.
Das war nicht erfolgreich. Ich habe den nicht so einfach vorschalten
können, wie ich dachte.
Hätte wahrscheinlich sowieso nicht den gewünschten Effekt gehabt, weil
das aus meiner Sicht ein stateless proxy ist.
Post by Holger Marzen
Ich habe jetzt Debian8 auf Debian9 upgedatet, das bringt Asterisk
13.14.1 mit. Nicht ganz so hoch, wie Du empfohlen hast, aber er bringt
pjsip mit. D.h. ich werde damit mal einen Trunk anlegen.
Nimm 13.16. Wenn Du es *richtig* machst, wie es eigentlich für die
Telekom nötig ist, wirst Du mit der von Dir genannten Version nur Ärger
haben.



Gruß,
Andreas
Holger Marzen
2017-06-23 04:54:12 UTC
Permalink
Post by Andreas Hartmann
Post by Holger Marzen
Ich habe jetzt Debian8 auf Debian9 upgedatet, das bringt Asterisk
13.14.1 mit. Nicht ganz so hoch, wie Du empfohlen hast, aber er bringt
pjsip mit. D.h. ich werde damit mal einen Trunk anlegen.
Nimm 13.16. Wenn Du es *richtig* machst, wie es eigentlich für die
Telekom nötig ist, wirst Du mit der von Dir genannten Version nur Ärger
haben.
Schauen wir mal. Bis auf die 15-Minuten-Trennung, wenn ich vom
Telekom-Anschluss einen 1&1-Kunden anrufe, lief sogar der Asterisk 11
gut. Hinter NAT und ohne auf dem Router irgendwelche Portforwardings
oder zusätzliche Paketfilterregeln anlegen zu müssen. Was die
Routereinrichtung angeht, ist die Telekom bei mir so einfach wie Sipgate.
Andreas Hartmann
2017-06-23 08:47:12 UTC
Permalink
Post by Holger Marzen
Post by Andreas Hartmann
Post by Holger Marzen
Ich habe jetzt Debian8 auf Debian9 upgedatet, das bringt Asterisk
13.14.1 mit. Nicht ganz so hoch, wie Du empfohlen hast, aber er bringt
pjsip mit. D.h. ich werde damit mal einen Trunk anlegen.
Nimm 13.16. Wenn Du es *richtig* machst, wie es eigentlich für die
Telekom nötig ist, wirst Du mit der von Dir genannten Version nur Ärger
haben.
Schauen wir mal. Bis auf die 15-Minuten-Trennung, wenn ich vom
Telekom-Anschluss einen 1&1-Kunden anrufe, lief sogar der Asterisk 11
gut. Hinter NAT und ohne auf dem Router irgendwelche Portforwardings
oder zusätzliche Paketfilterregeln anlegen zu müssen. Was die
Routereinrichtung angeht, ist die Telekom bei mir so einfach wie Sipgate.
Das ist nicht korrekt. Die Infrastruktur der Telekom ist mit hoher
Wahrscheinlichkeit viel komplexer als die von Sipgate. An einem Punkt
weiß ich es sicher (auch als Nichtkunde von sipgate):


dig +noall +answer _sip._udp.sipgate.de SRV
_sip._udp.sipgate.de. 28480 IN SRV 0 0 5060 sipgate.de.

dig +noall +answer _sip._udp.tel.t-online.de SRV
_sip._udp.tel.t-online.de. 234 IN SRV 0 5 5060
ims001.voip.t-ipnet.de.
_sip._udp.tel.t-online.de. 234 IN SRV 1 5 5060
ims002.voip.t-ipnet.de.


Siehst Du den Unterschied? Genau darüber stolpert Deine Asterisk-Version
mit hoher Wahrscheinlichkeit und bedankt sich mit regelmäßigen Crashes.

Das ist aber lange nicht alles. Es ist entscheidend, gegen welchen DNS
Du die Abfrage fährst. Ein freier DNS wird ein anderes Ergebnis liefern,
als der, der Dir von der Telekom zugewiesen wurde (hier bekommst Du
wahrscheinlich immer die SIP-Server zugewiesen, die für Dich explizit
von der Telekom vorgesehen sind und nicht irgendwelche neutrale, die
Hinz und Kunz zu Gesicht bekommt). Teste es selbst, falls es für Dich
Relevanz haben sollte, sprich, wenn Du die Auswahl zwischen
unterschiedlichen DNS-Servern haben solltest. Falls Du sowieso nur den
der Telekom hast, musst Du nur darauf achten, dass Asterisk bzw. pjsip
auch tatsächlich DNS SRV-Anfragen stellt und nicht mit den einfachen
DNS-Anfragen operiert. Das siehst Du im tcpdump, welche Anfragen gegen
den DNS gefahren werden.

Siehe hierzu auch
http://www.pjsip.org/pjsip/docs/html/group__PJSIP__RESOLVE.htm


Das wirkt sich außerdem hinterher in den zyklischen OPTIONS-Requests
aus. Mit den vom fremden DNS erhaltenen SIP-Servern wirst Du mit hoher
Wahrscheinlichkeit bei den OPTIONS-Requests als Antwort einen Fehler
bekommen - bei den SIP-Servern, die Du vom dir zugewiesenen DNS-Server
der Telekom bekommst, gehen die OPTIONS-Requests problemlos durch.


Wenn Du nicht mit SRV-DNS-Anfragen operierst, sondern mit normalen,
riskierst Du einen Ausfall, falls der *eine* zur Verfügung gestellte
SIP-Server nicht mehr erreichbar sein sollte. Im anderen Fall kann
Asterisk bzw. pjsip auf den zweiten Server ausweichen und weiter geht es.


Des weiteren gehe ich davon aus, dass die RTP-Ströme bei der Telekom
auch anders laufen als bei sipgate: die Telekom sendet die rtp-Ströme
über jede Menge, beliebige vom SIP-Server unabhängigen IP-Adressen. Das
machen auch nicht so viele Provider. Ist aber v.a. beim Firewalling /
iptables ein Thema. Wenn Du hier bisher keine engen Grenzen gesetzt
hast, wirst Du da natürlich auch nichts bemerken.


Es ist also alles andere als trivial, eine *ordentliche* Konfiguration
aufzusetzen (selbst mit der 13.16.er Version), die sehr stabil und
sicher läuft. Wenn man es aber mal geschafft hat, und genau weiß, was
man getan hat und die ganzen Zusammenhänge zwischen Asterisk und pjsip
kennt (die sind alles andere als trivial, weil sie gut versteckt sind),
bekommt man ein extrem gutes und stabiles Gesamtsystem.



Gruß,
Andreas
Thomas Gohel
2017-06-23 13:07:00 UTC
Permalink
Hallo Andreas,
Post by Andreas Hartmann
dig +noall +answer _sip._udp.sipgate.de SRV
_sip._udp.sipgate.de. 28480 IN SRV 0 0 5060 sipgate.de.
dig +noall +answer _sip._udp.tel.t-online.de SRV
_sip._udp.tel.t-online.de. 234 IN SRV 0 5 5060
ims001.voip.t-ipnet.de.
_sip._udp.tel.t-online.de. 234 IN SRV 1 5 5060
ims002.voip.t-ipnet.de.
Das ist aber lange nicht alles. Es ist entscheidend, gegen welchen
DNS Du die Abfrage fährst. Ein freier DNS wird ein anderes Ergebnis
liefern, als der, der Dir von der Telekom zugewiesen wurde
Die NAPTR-Abfrage zwischen dem Telekom DNS-Servern und Google sieht
hier jedenfalls fast identisch aus, bis auf einen Buchstaben ...

Von extern löst der DNS zum Schluß, also wenn man sich komplett bis
zum Ende durch arbeitet, immer auf eine "b-epp*"-Domain auf und von
intern immer auf eine "h-epp*"-Domain.


Telekom:

;; QUESTION SECTION:
;tel.t-online.de. IN NAPTR

;; ANSWER SECTION:
tel.t-online.de. 446 IN CNAME ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de. 86246 IN CNAME ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de. 86246 IN CNAME _h_-epp-001.isp.t-ipnet.de.
_h_-epp-001.isp.t-ipnet.de. 2559 IN NAPTR 0 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.


Google:

;; QUESTION SECTION:
;tel.t-online.de. IN NAPTR

;; ANSWER SECTION:
tel.t-online.de. 454 IN CNAME ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de. 77267 IN CNAME ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de. 77267 IN CNAME _b_-epp-001.isp.t-ipnet.de.
_b_-epp-001.isp.t-ipnet.de. 77267 IN NAPTR 0 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.



Tschau,

--------------
/ h o m a s
--
email : ***@gohel.de / ***@basicguru.de (PGP-Key available)
www : http://www.gohel.de / http://www.pbhq.de (PowerBASIC)
filter: html-postings, fullquotes, no realnames & no valid adresses
Andreas Hartmann
2017-06-23 14:53:17 UTC
Permalink
Hallo Thomas,
Post by Thomas Gohel
Hallo Andreas,
Post by Andreas Hartmann
dig +noall +answer _sip._udp.sipgate.de SRV
_sip._udp.sipgate.de. 28480 IN SRV 0 0 5060 sipgate.de.
dig +noall +answer _sip._udp.tel.t-online.de SRV
_sip._udp.tel.t-online.de. 234 IN SRV 0 5 5060
ims001.voip.t-ipnet.de.
_sip._udp.tel.t-online.de. 234 IN SRV 1 5 5060
ims002.voip.t-ipnet.de.
Das ist aber lange nicht alles. Es ist entscheidend, gegen welchen
DNS Du die Abfrage fährst. Ein freier DNS wird ein anderes Ergebnis
liefern, als der, der Dir von der Telekom zugewiesen wurde
Die NAPTR-Abfrage zwischen dem Telekom DNS-Servern und Google sieht
hier jedenfalls fast identisch aus, bis auf einen Buchstaben ...
Von extern löst der DNS zum Schluß, also wenn man sich komplett bis
zum Ende durch arbeitet, immer auf eine "b-epp*"-Domain auf und von
intern immer auf eine "h-epp*"-Domain.
;tel.t-online.de. IN NAPTR
tel.t-online.de. 446 IN CNAME ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de. 86246 IN CNAME ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de. 86246 IN CNAME _h_-epp-001.isp.t-ipnet.de.
_h_-epp-001.isp.t-ipnet.de. 2559 IN NAPTR 0 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
;tel.t-online.de. IN NAPTR
tel.t-online.de. 454 IN CNAME ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de. 77267 IN CNAME ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de. 77267 IN CNAME _b_-epp-001.isp.t-ipnet.de.
_b_-epp-001.isp.t-ipnet.de. 77267 IN NAPTR 0 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
Das passt leider immer noch nicht ganz, weil nicht nur relevant zu sein
scheint, dass Du den Telekom-DNS fragst, sondern auch noch, von _woher_
Du den Telekom DNS fragst. Von außerhalb der Telekom oder von innerhalb.
Wenn Du von innerhalb fragst, gehe ich stark davon aus, dass es auch
noch relevant ist, von welchem Ort aus Du fragst.
Ich bekomme für die interne Telekom DNS-Abfrage andere Namen, die auf
Deine abgeleitete Regel nicht passen :-) (die habe ich hier nicht gepostet).

Daher ist es zumindest für SIP ziemlich wichtig, a) den im Rahmen der
pppoe-Anmeldung zugewiesenen Telekom eigenen DNS zu verwenden, weil der
einen wahrscheinlich zum bestgeeigneten SIP-Server führt und b) dafür zu
sorgen, dass man SRV-DNS-Abfragen stellt, um immer 2 Server zu bekommen.

Wie gesagt, die Telekom'sche Gesamt-SIP-Architektur ist alles andere als
trivial (von außen betrachtet).


Gruß,
Andreas

Loading...