Gelöst
Verbindungsabbrüche SIP Telefonie, ausgehend, wegen Session Expiry.
vor 3 Jahren
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
9
Das könnte Ihnen auch weiterhelfen
vor 5 Jahren
597
0
3
vor 4 Jahren
988
0
2
vor 5 Jahren
1638
0
3
vor 2 Jahren
708
0
2
vor 3 Jahren
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
Antwort
von
vor 3 Jahren
Danke sehr für die Zeit, einen Test zu machen. Jedenfalls gut zu wissen dass UPDATEs bei dir funktionieren.
Wie gesagt ging's aber um reINVITEs als refresh Methode, die ja genauso vom Standard vorgesehen sind. Die der Server auch nicht reklamiert, und sich artig - um nicht zu sagen vorbildlich - dran hält, bei eingehenden Gesprächen. Nur bei ausgehenden scheint er zuverlässig in einen tiefen Schlummer zu verfallen.
Nu kannste sagen, ja dann mach doch UPDATEs. Die kann chan_sip aber nicht, den ich verwende aus RAM-Ersparnis Gründen auf dem Mini Router. So wie sicher manches andere Endgerät keine UPDATEs kann.
INVITEs sollten gehen. Wenn nicht möchte ich eine klare Fehlermeldung, die mir sagt dass dieser, etablierte Teil des Standards nicht unterstützt wird. Und nicht ein konfuses Gewurschtel, wo der Server sich mal dran hält, dann aber nicht obwohl er zuvor protokollgemäß zugestimmt hat.
Macht doch Sinn, oder nicht?
Edit:
Das ist was mein SIP client sagt was er kann
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Du siehst, da ist kein UPDATE. Wenn dem Server das nicht langt soll er's sagen. Das hieße aber auch, dass er nicht standardkonform operiert, und sicher eine ganze Reihe Endgeräte nicht ordentlich bedient. Und nicht so tun als ob er könnte aber dann doch nicht will.
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 3 Jahren
Hallo zusammen,
der Fehler liegt hier beim Anrufer, im SDP Offer/Answer Prozess.
Im initialen INVITE sendet der Anrufer folgenden SDP-Body:
Dann beim Session-Refresh mittels Re-INVITE wird im 200 OK folgendes geantwortet:
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):
Somit handelt es sich um eine harte RFC-Verletzung, die dann wiederum in der Folge zum fehlenden Session-Refresh führt...
0
Uneingeloggter Nutzer
Frage
von