‎Verbindungsabbrüche SIP Telefonie, ausgehend, wegen Session Expiry.

Telekom hilft Community

Telekom Business Community

Private customers

Telekom Shops

Contact

Solved

Verbindungsabbrüche SIP Telefonie, ausgehend, wegen Session Expiry.

3 years ago

Hallo Kommune

habe bei mir konsistent Verbindungsabbrüche nach ca 50 Minuten festgestellt, nur ausgehend. Client ist Asterisk 18 direkt auf einem OpenWRT Router, kein NAT. Magenta Vertrag, 100MBit. Telefonie Server Situation:

$ nslookup -querytype=SRV _sip._udp.tel.t-online.de
_sip._udp.tel.t-online.de service = 10 0 5060 n-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de service = 20 0 5060 d-epp-100.edns.t-ipnet.de.
_sip._udp.tel.t-online.de service = 30 0 5060 h2-epp-100.edns.t-ipnet.de.

Der erste, 217.0.25.97, wird genommen.

Was passiert ist Folgendes, laut Packet Logs genommen direkt vom WAN Interface. Ich sende den initialen INVITE raus, das übliche "unauthorized" etcetera folgt, dann kommt das Okay, wo der Server sagt dass er der Refresher sein will, bzgl. Session Expiry:

Session-Expires: 1800;refresher=uas

Er ist der UAS, weil ich den INVITE gesendet habe. Asterisk stimmt zu, und von nun an ist es Sache des Telekom Servers die Sitzung mit reINVITES am Leben zu halten. Expiry ist 30 Minuten, also sollte der erste reINVITE nach 15 kommen.

Dann kommt auch einer, aber erst nach 22 Minuten. Hier erklärt sich wiederum der Telekom Server für die Geschichte verantwortlich:

Session-Expires: 1800;refresher=uac

Klar, UAC diesmal weil der ja den INVITE geschickt hat. Asterisk stimmt zu, alles klar und sauber. Und dann hört man gar nix mehr vom Telekom Server. Außer 30 Minuten später, also nach den vollen 1800 Sekunden, wo er sein BYE schickt mit der Begündung

Reason: SIP;cause=408;text="Request Timeout (1:26)"

D.h. obgleich er sich für die reINVITES verantwortlich erklärt schickt er genau einen und das war's. Dann lässt er die Sitzung einfach auslaufen und kappt schließlich die Verbindung.

Wie gesagt, das passiert nur ausgehend. Eingehend erklärt er sich auch verantworlich, diesmal von Beginn an als UAC, da er ja den ersten INVITE schickt, und dann kommen schön pünktlich und sauber, wie zuhause gelernt, alle 15 Minuten seine reINVITES. Ich kann ihm sogar sagen, bei eingehenden Verbindungen, dass mein Asterisk die Sache übernehmen soll. Dann sagt Asterisk "refresher UAS", der Telekom Server schluckt das und dann schickt Asterisk alle 15 Minuten reINVITES, diesmal natürlich annoncierend dass er als UAC die Sache in der Hand behält, und es gibt nullo Problemo, egal wer die reINVITES macht.

Wie gesagt, bei eingehenden Verbindungen. Bei ausgehenden scheint Telekom Server unter Gedächtnisschwund zu leiden und, nach dem ersten reINVITE, zuverlässig zu vergessen wofür er sich eigentlich verantwortlich erklärt hat. Wo wendet man sich mit sowas hin?

1130

3 years ago

direktorstellvertreter

Bei ausgehenden scheint Telekom Server unter Gedächtnisschwund zu leiden und, nach dem ersten reINVITE, zuverlässig zu vergessen wofür er sich eigentlich verantwortlich erklärt hat.

Bei ausgehenden scheint Telekom Server unter Gedächtnisschwund zu leiden und, nach dem ersten reINVITE, zuverlässig zu vergessen wofür er sich eigentlich verantwortlich erklärt hat.

direktorstellvertreter
Bei ausgehenden scheint Telekom Server unter Gedächtnisschwund zu leiden und, nach dem ersten reINVITE, zuverlässig zu vergessen wofür er sich eigentlich verantwortlich erklärt hat.

Kann ich für "meinen" Telekomserver so nicht bestätigen.

Da kommt das UPDATE alle 15min.

Hast du schon mal mit einem Softphone, wie z.B. PhonerLite getestet?

7
Answer
from
3 years ago

direktorstellvertreter

Du siehst, da ist kein UPDATE.

Du siehst, da ist kein UPDATE.

direktorstellvertreter
Du siehst, da ist kein UPDATE.

Das sehe ich.

Leider bietet keines meiner Endgeräte die Möglichkeit das UPDATE rauszukonfigurieren.

Kann also die Refresh-Methode INVITE nicht testen.

Es gab hier mal einen SIP-Spezialisten der Telekom, ob der allerdings noch aktiv ist, weiß ich nicht.

@Meester Proper

Answer
from
3 years ago
Ich kann mir das gerne ansehen.
Dazu benötige ich allerdings ein aktuelles Beispiel (<7 Tage) mit A- und B-Rufnummer per PN.
Answer
from
3 years ago
Okay. Jedenfalls danke.

Weiste, ich würde ja den anderen SIP Treiber für Asterisk nehmen, der alles und dann noch drei Sachen mehr kann, aber der bläst den Prozess, RAM mäßig, von 30MB gleich auf 60MB auf. Auf 'nem kleinen TP-Link Archer Router. Das macht natürlich wenig Freude. Und ich bin sicher nicht der Typ der, sobald die Gegenstelle Zicken macht, gleich losrennt und sich für 200 Euro oder was 'ne neue Box kauft.

Zudem hat dieses Setup mit meinem früheren, kleineren Magenta Vertrag zuverlässig und 100% stabil funktioniert. 4 satte Jahre lang, kein Problem. Also, unter uns gesagt, ich bin da ziemlich sicher dass das Server Teil entweder fehlkonfiguriert ist oder mal 'nen tüchtigen Reboot braucht. Wie gesagt, ein erstes reINVITE kommt ja sogar an, wenn auch 7 Minuten verspätet.

Ich sende dem Meister Proper vielleicht doch mal 'ne Nachricht. Vielleicht kann er ja alles wieder blitzblank machen.

Wie gesagt, danke. Wertvoller Input wird hier immer geschätzt.
Unlogged in user
Answer
from

Accepted Solution

accepted by

3 years ago

Hallo zusammen,

der Fehler liegt hier beim Anrufer, im SDP Offer/Answer Prozess.

Im initialen INVITE sendet der Anrufer folgenden SDP-Body:

Protocol Version : v=0 
Session Owner/Creator and session identi : o=root 936480392 936480393 IN IP4 xx.xxx.xxx.xx 
Session Name : s=- 
Session Connection Data : c=IN IP4 xx.xxx.xxx.xx 
Time the session is active : t=0 0 
Media Name : m=audio 30058 RTP/AVP 8 9 101 
Media : audio 
Port : 30058 
Protocol type : RTP/AVP 
Media Format : 8 = PCMA
Media Format : 9 = G722
Media Format : 101 = dynamic
Media Attribute : a=rtpmap:8 PCMA/8000 
Media Attribute : a=rtpmap:9 G722/8000 
Media Attribute : a=rtpmap:101 telephone-event/8000 
Media Attribute : a=fmtp:101 0-16 
Media Attribute : a=ptime:20 
Media Attribute : a=maxptime:150 
Media Attribute : a=sendrecv

Dann beim Session-Refresh mittels Re-INVITE wird im 200 OK folgendes geantwortet:

Protocol Version : v=0 
Session Owner/Creator and session identi : o=root 936480392 936480393 IN IP4 xx.xxx.xxx.xx 
Session Name : s=- 
Session Connection Data : c=IN IP4 xx.xxx.xxx.xx 
Time the session is active : t=0 0 
Media Name : m=audio 30058 RTP/AVP 8 101 
Media : audio 
Port : 30058 
Protocol type : RTP/AVP 
Media Format : 8 = PCMA
Media Format : 101 = dynamic
Media Attribute : a=rtpmap:8 PCMA/8000 
Media Attribute : a=rtpmap:101 telephone-event/8000 
Media Attribute : a=fmtp:101 0-16 
Media Attribute : a=ptime:20 
Media Attribute : a=maxptime:150 
Media Attribute : a=sendrecv

Interessant ist hier die o-line. Schaut man einmal in RFC8866 bezüglich Syntax, heißt es dort:

     o=<username> <sess-id> <sess-version> <nettype> <addrtype>
     <unicast-address>

<sess-version> is a version number for this session description. Its usage is up to the creating tool, so long as <sess-version> is increased when a modification is made to the session description. Again, as with <sess-id> it is RECOMMENDED that a Timestamp be used.

In beiden SDP-Bodys ist die Session Version die selbe, aber es gab eine Änderung im SDP-Body (m-line ohne Payloadtype 9).

Dies widerspricht Abschnitt 8 des RFC3264 (sess-version muss inkrementiert werden):

When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP.  If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number.

Somit handelt es sich um eine harte RFC-Verletzung, die dann wiederum in der Folge zum fehlenden Session-Refresh führt...