‎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
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.
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...