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

Meister Proper, was soll ich sagen? Propere Arbeit erster Güte. Danke, wirklich. Klasse.

Also, Asche auf mein Haupt, sei zu allererstmal festgestellt. Hatte ich nicht behauptet, dieselbe Konfiguration hätte zuvor viele Jahre getan? Gelogen! muss ich jetzt leider selber feststellen. Ich hatte nämlich früher ausschließlich den alaw Codec aktiviert, aber irgendwann kürzlich mal den g722 hinzugenommen. Und egal wo der Fehler - auf meiner Seite - jetzt wirklich begraben liegt, ob Bug oder Fehlkonfiguration oder was, das war natürlich hier der fatale Unterschied.

Also, ich mach jetzt erst nochmal einen Test, wieder nur mit alaw - obgleich das Ergebnis jetzt ziemlich vorhersagbar ist - und dann werde ich mir nochmal anschauen was hier - auf meiner Seite, klar - wirklich das Problem ist.

Aber nochmal, das war jetzt in der Tat ein echter Hochgenuss. Problem erkannt, sauber isoliert und kristallklar dargestellt, und dem Männle (mir) damit wirklich geholfen. Spitze. Echt.

Edit:

Tja, Freunde der Sonne, was sagt man dazu. Jetzt geht's, ganz genauso wie in den guten alten Zeiten. Also, was haben wir heute gelernt? Lügen, auch ungewollte, haben kurze Beine. Das schreiben wir uns jetzt auf'n Zettel und heften den an den Kühlschrank, damit wir diese wertvolle Lektion nicht so bald vergessen.

Um die Sache abzuschließen für andere chan_sip Nutzer die eventuell hierüber stolpern, dies ist tatsächlich ein Bug in chan_sip. Das Modul inkrementiert seine SDP Session Version (p->sessionversion in add_sdp()) rein reaktiv, nämlich nur wenn die Gegenstelle ihrerseits ihre Version inkrementiert hat. Das ist natürlich zuwenig.

Wie gesagt, das Ganze fällt überhaupt nicht auf wenn man nur alaw verwendet (allow=!all,alaw). Wenn man aber einen zweiten Codec, namentlich g722, hinzunimmt (allow=!all,alaw,g722), und der Tkom Server antwortet "nehmen wir alaw", also im Rahmen des initialen Aushandlungsprozesses der Session, dann modifiziert chan_sip seine Session ohne seine Version intern hochzuzählen, was es eigentlich mit dem letzten ACK im Sessionaufbau tun müsste.

Witzigerweise, und das ist wirklich lustig, haben die einen Hack implementiert mit dem Clients begegnet werden soll die ihrerseits ihre Version Nummer nicht korrekt hochzählen. Der entsprechende Konfigurationsparameter lautet "ignoresdpversion". Wenn man den auf yes setzt - nur für ausgehende Tkom Verbindungen natürlich - inkrementiert chan_sip seine Version Nummer *jedes Mal* wenn es seinen Session Zustand kommuniziert. Das heißt, es wird dem Server vorgegaukelt dass sich die Session geändert hat, und der Server muss dann checken was genau und ob Handlungsbedarf besteht, was in der Regel dann eben nicht der Fall ist.

So mit einem Server umzuspringen ist natürlich nicht die reine Schule. Aber den Check, haben wir ja gerade gelernt, macht der Tkom Server sowieso, das heißt der rechentechnische Mehraufwand auf seiner Seite sollte sich in Grenzen halten. Und tatsächlich, mit diesem fiesen Trick funktioniert die ganze Sache. D.h. damit werden wieder Session Refreshes regelmäßig vom Tkom Server gesendet, auch wenn man g722 mit im Sortiment hat. Kann natürlich sein, dass es Seiteneffekte gibt die ich nicht überblicke. Aber ein kleiner Test ist anstandslos durchgelaufen, d.h. mit jedem Refresh hat der Server richtig erkannt dass es trotz des Inkrementes nichts zu tun gibt, also an der Session nicht rumgefummelt werden muss.

Dies nur als Randbemerkung. Ob man HD Audio, wie es so schön heißt, wirklich braucht sei sowieso mal dahingestellt. Anscheinend gibt's da ja ohnehin jede Menge Probleme, etwa mit Mobilfunkteilnehmern. Und mit dieser Beobachtung, denke ich, können wir die Sache dann wirklich zu den Akten legen.

Wie gesagt, ganz herzlichen Dank nochmal für die tolle Unterstützung. Ich hätt' das nie rausbekommen, auch nicht mit Ratsuche auf anderen einschlägigen Foren. Da bin ich mir ziemlich hundertprozentig sicher.