[Gelöst] Telekom und die berühmten 15 Minuten

[AdamSapfel]

Ich versuche seit längerem Asterisk 18.2.0 und pjsip mit Telekom-voip zu verwenden. Es funktioniert alles ausser dass ausgehende Gespräche nach etwas 15 Minuten durch die Telekom mit mehreren "BYE" abgebrochen werden. Sonst gibt es keine Fehlermeldungen. Zu diesem Thema gibt es im Internet viel zu lesen, ich habe aber bislang keine funktionierende Konfiguration erstellen können. Accounts anderer Anbieter wie Sipgate haben dieses Problem nicht! Hier wie ich es aktuell konfiguriert habe:

[transport](!)
type=transport
local_net=192.168.0.0/16

[transport_udp](transport)
protocol=udp
bind=0.0.0.0:5060

[transport_dsl](transport)
protocol=udp
bind=0.0.0.0:35060
external_media_address=GEHAIM.dyndns.com
external_signaling_address=GEHAIM.dyndns.com


[Telekom]
type=auth
auth_type=userpass
[email protected]
password=GEHAIM
realm=tel.t-online.de

[Telekom]
type=endpoint
transport=transport_dsl
allow=!all,g722,alaw,ulaw,g726,gsm
outbound_auth=Telekom
timers=no
timers_sess_expires=900
context=context

[Telekom]
type=identify
endpoint=Telekom
;match=tel.t-online.de
match=217.0.0.0/13


[Telekom]
type=aor
contact=sip:tel.t-online.de


[Telekom_endpoint](!)
type=endpoint
transport=transport_dsl
allow=!all,g722,alaw,ulaw,g726,gsm
outbound_auth=Telekom
timers=no
timers_sess_expires=900
context=context_invalid
rtp_symmetric=yes
force_rport=yes
direct_media=no
rewrite_contact=yes
aors=Telekom
from_domain=tel.t-online.de
ice_support=yes

[Telekom1_out](Telekom_endpoint)
outbound_proxy=sip:[email protected]\;lr
callerid=012345000001
from_user=012345000001

[Telekom2_out](Telekom_endpoint)
outbound_proxy=sip:[email protected]\;lr
callerid=012345000002
from_user=012345000002

[Telekom3_out](Telekom_endpoint)
outbound_proxy=sip:[email protected]\;lr
callerid=012345000003
from_user=012345000003


[Telekom_registration](!)
type=registration
transport=transport_dsl
retry_interval=180
expiration=600
outbound_auth=Telekom
server_uri=sip:tel.t-online.de
forbidden_retry_interval=60
auth_rejection_permanent=false

[Telekom1_out](Telekom_registration)
contact_user=012345000001
outbound_proxy=sip:[email protected]\;lr
client_uri=sip:[email protected]

[Telekom2_out](Telekom_registration)
contact_user=012345000002
outbound_proxy=sip:[email protected]\;lr
client_uri=sip:[email protected]

[Telekom3_out](Telekom_registration)
contact_user=012345000003
outbound_proxy=sip:[email protected]\;lr
client_uri=sip:[email protected]


rtp.conf:
[general]
rtpstart=37000
rtpend=37100
stunaddr=stun.t-online.de

dnsmgr.conf:
enable=yes
refreshinterval=60

 

[sunnyman]

Ich fahre seit Jahren gut mit folgenden Werten für das registration-Objekt:
retry_interval = 60
forbidden_retry_interval=120
expiration=480

Was machst du eigentlich mit:
timers=no
timers_sess_expires=900

Die Session-Timer werden ausgeschaltet, aber trotzdem auf einen eigenen Wert gesetzt?

Dann sieht mir dein Setup einerseits so aus, als würdest du mit Portforwarding arbeiten, andererseits hast du aber diverse NAT-Optionen und -Helferlein wie den dnsmgr, STUN und ICE aktiv. Ist das Absicht?

Die "berühmten 15 Minuten" gibt es bei anderen Providern auch, und zwar meist dann, wenn das Zeitfenster für die Re-Registrierung zu groß gewählt ist. Die Registrierung wird erfolgreich durchgeführt, du telefonierst, und der Timer auf Provider-Seite läuft aus, bevor das Asterisk das nächste REGISTER schickt.

 

[AdamSapfel]

Danke, ich versuche es mal bei der "registration" damit. "timers_sess_expires" ist ein Überrest von den ganzen Experimenten vorher. Gefühlt habe ich jede Kombination ausprobiert, nur nicht die richtige.
Der Asterisk läuft nicht direkt auf dem Speedport, braucht also NAT. Die RTP Ports hab ich deshalb fest eingestellt und im Router den Bereich weitergeleitet. Ist das so nicht okay?

 

[sunnyman]

Danke, ich versuche es mal bei der "registration" damit. "timers_sess_expires" ist ein Überrest von den ganzen Experimenten vorher. Gefühlt habe ich jede Kombination ausprobiert, nur nicht die richtige.

Ich kann die Verzweiflung an der Stelle nachvollziehen, aber ich fahre die Devise "weniger ist mehr". So ein PJSIP oder noch besser chan_sip bringt für alles einigermaßen gute und "sichere" Defaults mit.

So führen immer mehr explizite Einstellungen meist dazu, dass man den Überblick verliert und, wie oben, man Einstellungen drin hat die keinen Sinn mehr geben oder sich gar "beharken".
Es schadet auch nicht, sich vor der Übernahme von Settings durchzulesen, was die eigentlich genau machen und ob das - vom Grundsatz - beim Problem helfen könnte:

res_pjsip - Asterisk Documentation

wiki.asterisk.org

Der Asterisk läuft nicht direkt auf dem Speedport, braucht also NAT. Die RTP Ports hab ich deshalb fest eingestellt und im Router den Bereich weitergeleitet. Ist das so nicht okay?

Du kannst es machen wie du selbst es möchtest. Du hast Recht, grundsätzlich kommt bei Portforwarding auch NAT zum Einsatz. Allerdings ist das was typischerweise mit NAT gemeint ist, das dynamische Zuweisen von Ports. Dabei spielt es auch eine Reihe, ob bei ausgehenden Verbindungen der Router das Portmapping lang genug offen lässt, etc.
Man kann das auch mit den heute nicht mehr so gebräuchlichen Begriffen anschaulicher erklären: Portforwarding hieß mal "static NAT" und das was heute üblicherweise mit NAT gemeint ist, ist "dynamic NAT".
Soll heißen: bei Portforwarding bzw. statischem NAT muss der Router auch NAT machen, aber du machst eben eine statische Zuweisung eines Port-Bereichs zu einer IP.
Du kannst dir sicher sein, dass der RTP-Port den Asterisk sich aussucht auch der ist der extern verwendet wird, etc.
Damit übergehst du aber auch die Router-interne Firewall. Soll heißen, dein Speedport leitet *alle* Pakete, die auf 37000 bis 371000 reinkommen, direkt an dein Asterisk weiter.
Hast du 5060 auch per Portforwarding zum Asterisk durchgestellt? Das sollte man nur machen wenn der Server entsprechend geschützt ist.

Wie gesagt: Deine Einstellungen sehen für mich nach einem Mischmasch von Einstellungen für beide NAT-Varianten aus.

 

[AdamSapfel]

Telkom-voip ist durch die ganzen Standarderweiterungen sehr frustrierend. Ich bin kurz davor Telekom komplette rauszuwerfen und nur noch andere Provider zu nutzen. Dann würden Festnetzgespräche zwar etwas kosten, aber länger als 15 Minuten möglich sein. Ich hab extra auf Asterisk 18 geupdated in der Hoffnung dass es damit geht. Aber selbst damit ist weiterhin mit der Telekom SSL nur über einen extra Patch möglich!

Ich hab nur die RTP Ports weitergeleitet, nicht 35060 und 5060. Eine Registrierung ist nur intern oder über VPN vorgesehen. Ausserdem erlaub der Speedport sowieso keine Forwards bestimmter Ports unter anderem 5060

Falls #2 nicht hilft miste ich die Konfig etwas aus und hoffe das Beste

 

[chrsto]

Portweiterleitungen sind nicht notwendig. Bei Telekom VoIP werden RTP Verbindungen nur von dir in Richtung Telekom aufgebaut und die Sprachpakete darüber in beide Richtungen ausgetauscht.

 

[AdamSapfel]

Intressant, dann könnte ich die Portweiterleitung und festen RTP Ports löschen. oder trifft das nur auf die Telekom zu? Ich hab noch andere Provider wie Sipgate

 

[chrsto]

Mir ist außer 1&1 kein Provider bekannt, wo überhaupt ein Port (IPv4) weitergeleitet werden müsste.

 

[AdamSapfel]

Die verkürzte Config, leider immer noch mit Abbrüchen bei ausgehenden Gesprächen nach 15 Minuten.

[Telekom]
type=auth
auth_type=userpass
[email protected]
password=GEHAIM
realm=tel.t-online.de

[Telekom_in]
type=endpoint
transport=transport_dsl
allow=!all,g722,alaw,ulaw,g726,gsm
direct_media=no
outbound_auth=Telekom
context=context_in

[Telekom_in]
type=identify
endpoint=Telekom_in
match=217.0.0.0/13


[Telekom]
type=aor
contact=sip:tel.t-online.de


[Telekom_endpoint](!)
type=endpoint
transport=transport_dsl
allow=!all,g722,alaw,ulaw,g726,gsm
direct_media=no
outbound_auth=Telekom
context=context_invalid
aors=Telekom
from_domain=tel.t-online.de

[Telekom1_out](Telekom_endpoint)
outbound_proxy=sip:[email protected]\;lr
from_user=012345000001
callerid=012345000001

[Telekom2_out](Telekom_endpoint)
outbound_proxy=sip:[email protected]\;lr
from_user=012345000002
callerid=012345000002

[Telekom3_out](Telekom_endpoint)
outbound_proxy=sip:[email protected]\;lr
from_user=012345000003
callerid=012345000003


[Telekom_registration](!)
type=registration
transport=transport_dsl
outbound_auth=Telekom
server_uri=sip:tel.t-online.de
auth_rejection_permanent=false
retry_interval=60
forbidden_retry_interval=120
expiration=480

[Telekom1_out](Telekom_registration)
contact_user=012345000001
client_uri=sip:[email protected]
outbound_proxy=sip:[email protected]\;lr

[Telekom2_out](Telekom_registration)
contact_user=012345000002
client_uri=sip:[email protected]
outbound_proxy=sip:[email protected]\;lr

[Telekom3_out](Telekom_registration)
contact_user=012345000003
client_uri=sip:[email protected]
outbound_proxy=sip:[email protected]\;lr

 

[sunnyman]

Beim AOR habe ich mehr:
qualify_frequency = 60
contact=sip:tel.t-online.de
default_expiration=585

 

[chrsto]

Die qualify_frequency wäre wichtig.

 

[AdamSapfel]

Das wars! Es konnten 2 Gespräche über 15 Minuten geführt werden! Mit tcpdump sehe ich nun ein mal pro Minuten ein "OPTIONS" Paket.
Allerdings habe ich wohl eine der NAT Optionen die es noch in #1 gab zuviel entfernt. In der Firewall vom Asterisk sehe ich bei Gesprächsaufbau eingehende UDP Verbindungen von SPT=5060 auf DPT=35060 vom Telekomserver aus. Und das obwohl es für diesen Port keine Weiterleitung im Speedport gibt! Scheinbar macht der Speedport das von sich aus

 

[chrsto]

Nein, das ist keine Weiterleitung. Dein Asterisk baut eine Verbindung zum Telekom Server auf und hält die (35060 -> 5060) und über diese Verbindung meldet sich die Telekom auch bei dir.

 

[AdamSapfel]

Da es eingehend keine Portweiterleitung gibt dürfte es diesen Zugriffsversuch auf den Asterisk nicht geben. Vielleicht gab es einen IP Wechsel und die verbindung war noch related

 

[essex_man]

SIP Server verwenden entweder OPTIONS oder re-invite um waehrend eines Gespraeches zu testen ob der SIP Client noch online ist (der RTP stream kann vom SIP server nicht ueberwacht werden weil der zum Media Gateway geht).

Das re-invite kommt alle 15 Minuten, ich hatte mich vor ein paar Jahren mit dem Thema beschaeftigt (Asterisk an einem Metaswitch SIP Server). Kann nur leider die sip.conf gerade nicht mehr finden, kann mich aber dunkel daran erinnern dass man Asterisk das Antworten auf Re-Invite beibringen musste. Wenn der Asterisk auf das re-invite nicht antwortet, wird das Gespraech abgebrochen.

 

[AdamSapfel]

Seit ich die in #10 vorgeschlagenen Zeilen hinzugefügt habe, kommen die OPTIONS jede Minute, auch wenn keine Gespräche geführt werden!
Beispiel:

asterisk:305060 > telekom.5060: SIP: OPTIONS sip:tel.t-online.de SIP/2.0
telekom:.5060 > asterisk.35060: SIP: SIP/2.0 200 In Ordnung

Und dadurch gehen ausgehende Gespräche. Aber nicht je Rufnummer, sondern genau einmal.
Vielleicht setze ich qualify_frequency auf 5 oder 8 Minuten

 

[essex_man]

SIP Options request Intervall kann auf dem Server konfiguriert werden, default 60 Sekunden. Das haelt den Asterisk registriert. Re-Invite wirkt sich nur auf das Gespraech aus.

 

[sonyKatze]

dadurch gehen ausgehende Gespräche. Aber nicht je Rufnummer, sondern genau einmal.

Stehe ein wenig auf dem Schlauch, was „einmal“ bzw. „Rufnummer“ bedeutet: Kannst Du einen Teilnehmer anrufen und dann geht es. Rufst Du diesen Teilnehmer wieder an, geht es. Aber wenn Du einen anderen Teilnehmer von diesem SIP-Konto (= Rufnummer) anrufst, dann geht es nicht mehr? Heißt das, es geht immer noch nicht sauber?

Vielleicht setze ich qualify_frequency auf 5 oder 8 Minuten

Das sind die OPTIONs und die sind eigentlich nur dafür da, dass eingehende Anrufe ankommen: INIVITE. Während einem Gespräch sind die dafür da, dass re-INVITE (= Session-Timers; RFC 4028) ankommen. Der Wert ergibt sich durch Deine Firewall. Den Wert kannst Du ermitteln …

Mir ist außer 1&1 kein Provider bekannt, wo überhaupt ein Port (IPv4) weitergeleitet werden müsste.

Und je nach Implementierung des VoIP/SIP-Clients nicht einmal das …

Speedport

1. Welcher Telekom Speedport ist das genau?
2. Wenn es der Speedport Hybrid oder der Speedport Pro (Plus) ist, nutzt Du den mit einem Hybrid-Tarif?
3. Besteht die Möglichkeit eine FRITZ!Box, DrayTek bzw. Lancom testweise zu verwenden?

Bei letzteren beiden kannst Du das Timeout für die NAT-Bindings direkt im Router einstellen. Bei der FRITZ!Box sind die Timeouts bekannt. Das würde den Test-Aufbau vereinfachen, weil wir eine unbekannte „Kiste“ dazwischen haben. Keiner weiß deren Timeouts bzw. ob die nicht doch SIP-ALG macht.

 

[AdamSapfel]

Stehe ein wenig auf dem Schlauch, was „einmal“ bzw. „Rufnummer“ bedeutet

Ich habe 3 Rufnummern von der Telekom die auch am Asterisk registriert sind. Es wird aber nicht für jede einzelne 1 mal pro Minute ein OPTIONS gesendet, sonder insgesammt 1 pro Minute, egal wie viele Telefonnummern aktiv sind. Da es aber keine Probleme bei ausgehenden Telefonaten bei über 15 Minuten mehr gab ist das für mich okay

Bei eingehenden Gesprächen hab ich tatsächlich noch ab und an Probleme. Der Anrufer hört dann gar nichts statt einem Klingeln.
Ich hab den ältesten Speedport Hybrid mit Hybrid, bzw es wurde nach LTE Option umbenannt. Auch wenn die Telekom schon vor 5 Jahren Voice Redundancy groß angekündigt hat, hat sie es hier bislang noch nicht geschafft Voip über LTE zu erlauben. Daher taggt der Raspberry mit dem Asterisk für Diff-Serv Voip der Telekom.
Ich hab überhaupt erst einen Asterisk installiert, da AVM mit 7.25 annimmt dass es überall Voice Redundancy gäbe, und dadurch sich keine Telekom-Nummern mit der Fritzbox mehr registrieren liessen

 

[chrsto]

Bei eingehenden Gesprächen hab ich tatsächlich noch ab und an Probleme. Der Anrufer hört dann gar nichts statt einem Klingeln.

Das ist meistens ein Early Media Problem. Manchmal generiert der Provider den Rufton, manchmal wird erwartet, dass du das "generierst".

Auch wenn die Telekom schon vor 5 Jahren Voice Redundancy groß angekündigt hat, hat sie es hier bislang noch nicht geschafft Voip über LTE zu erlauben.

Das funktioniert auch, allerdings nur, wenn die Rufnummern im Speedport registriert und auch dort über analog/DECT genutzt werden und auch nur wenn einmalig (regelmäßig?) DSL zur Verfügung stand (steht).