‎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

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