Gesprächsabbrüche nach 15 Minuten bei Weiterleitungen im SIP-Trunk der Telekom (DeutschlandLAN SIP-Trunk)

[gehtdoch]

Hallo zusammen,

Ich beobachte wiederholt abbrechende Gespräche nach 15 Minuten, welche innerhalb eines DeutschlandLAN SIP-Trunks umgeleitet wurden (Avaya-Anlage vermutlich). Typisches Homeoffice-Szenario (MA hat auf privates Telefon umgeleitet am Telefon im Büro). Im Detail:

Teilnehmer A -> DeutschlandLAN SIP-Trunk / Rufumleitung -> Teilnehmer B​

TN A - Provider ist Telekom AllIP (MagentaZuhause / Asterisk / ich), TN B vermutlich auch AllIP (Aussage: "Provider ist Telekom")

Gespräche in die genannte Richtung brechen regelmäßig nach 15 Minuten ab. Leider habe ich von den konkreten Abbrüchen keinen Trace vorliegen. Ich habe in den CDR keine erfolgreichen von Asterisk ausgehenden Gespräche > 15 Minuten gesehen im Zusammenhang mit einer Rufumleitung im SIP-Trunk.

• Calls direkt von Asterisk auf die Devices des SIP-Trunks sind kein Problem (also ohne Umleitung). ​
• Auch Calls vom TN B über eine Rufumleitung im SIP-Trunk zu Asterisk sind kein Problem.​
• Calls direkt aus dem SIP-Trunk zu Asterisk sind ebenfalls kein Problem.​

Ich habe nun zu Tracezwecken versucht, die Problematik nachzustellen, indem ich mich über die Rufumleitung selbst angerufen habe (so sieht man sowohl den ausgehenden Call als auch den eingehenden Call). Dies erbrachte die folgenden Erkenntnisse:

1. Problem ist mehrfach nicht nachstellbar - tritt nicht auf (egal ob mit oder ohne Verschlüsselung).​
2. Die Totmannschaltung im Zusammenhang mit dem Telekom SIP-Trunk scheint mir ziemlich schräg - habe ich so bisher noch nirgendwo gesehen - ich vermute aber hier die Schwachstelle:
   Beim ausgehenden Call-Leg (von Asterisk zur Rufumleitung) erfolgt alle 15 Minuten eine Totmannprüfung (soweit normal), jedoch doppelt: sowohl via update als auch via ReInvite (in genau dieser Reihenfolge im Abstand von 0,03 s)
   Beim eingehenden Call-Leg erfolgt die Totmannschaltung sogar alle 7,5 Minuten - aber nur via ReInvite.
   Diese Umsetzung einer Totmannschaltung habe ich im AllIP bisher noch zu keinem Provider gesehen. Alle mir bekannten gehen via update alle 15 Minuten problemlos. Mir scheint, dass hier zwei Totmannschaltungen (die der AllIP-Plattform und die vom SIP-Trunk sich ins Gehege kommen und nicht sauber getrennt sind: Die AllIP-Plattform fährt einerseits die eigene (alle 15 Minuten den Update) und gibt andererseits die vom SIP-Trunk weiter via ReInvite (ausgehendes Call-Leg), während im eingehenden Call-Leg die AllIP-Prüfung nicht vorhanden zu sein scheint sondern nur die vom SIP-Trunk durchschlägt).
   Das SIP-Protokoll sieht in den Tests trotz allem fehlerfrei aus (hier trat ja auch das Problem überraschenderweise nicht auf).​

Jetzt stehe ich natürlich da - einerseits ist ein Problem definitiv vorhanden - andererseits bekomme ich es nicht nachgestellt. Super Bedingungen für ein Ticket.

Hat irgendjemand eine Idee, woran das liegen könnte bzw. hatte das selbe Problem auch schon und sogar zufällig eine Lösung dafür? Oder sonstige Anstöße, wie man das Ganze noch reproduzierbar nachstellen könnte? Oder vielleicht gibt es ja zufällig jemand mit Innensichten vom Telekom SIP-Trunk oder der AllIP-Plattform?

Danke im Voraus!

 

[Meester Proper]

Ich beobachte wiederholt abbrechende Gespräche nach 15 Minuten, welche innerhalb eines DeutschlandLAN SIP-Trunks umgeleitet wurden (Avaya-Anlage vermutlich). Typisches Homeoffice-Szenario (MA hat auf privates Telefon umgeleitet am Telefon im Büro). Im Detail:

Teilnehmer A -> DeutschlandLAN SIP-Trunk / Rufumleitung -> Teilnehmer B​

TN A - Provider ist Telekom AllIP (MagentaZuhause / Asterisk / ich), TN B vermutlich auch AllIP (Aussage: "Provider ist Telekom")

Wie wird denn die Umleitung realisiert per SIP302 Signalisierung auf dem eingehenden Ruf, so dass die Telekom-Plattform die Verbindung zum C-Teilnehmer aufbaut oder baut der B-Teilnehmer einen zweiten Call zu Teilnehmer C auf?

Die Totmannschaltung im Zusammenhang mit dem Telekom SIP-Trunk scheint mir ziemlich schräg

Das ist keine "Totmannschaltung" sondern ein regulärer Session Refresh, wie in RFC4028 beschrieben.

Beim ausgehenden Call-Leg (von Asterisk zur Rufumleitung) erfolgt alle 15 Minuten eine Totmannprüfung (soweit normal), jedoch doppelt: sowohl via update als auch via ReInvite (in genau dieser Reihenfolge im Abstand von 0,03 s)

Welcher Session-Refresh Parameter werden denn beim Aufbau der Session ausgehandelt? Sprich welcher UA ist der Refresher?

Beim eingehenden Call-Leg erfolgt die Totmannschaltung sogar alle 7,5 Minuten - aber nur via ReInvite.

Hier wird offenbar ein Session-Timer von 900s ausgehandelt. Gemäß RFC4028 wird dann regulär zur Hälfte der Timer-Zeit ein Refresh vorgenommen => 7,5 Minuten.

 

[gehtdoch]

Wie wird denn die Umleitung realisiert per SIP302 Signalisierung auf dem eingehenden Ruf, so dass die Telekom-Plattform die Verbindung zum C-Teilnehmer aufbaut oder baut der B-Teilnehmer einen zweiten Call zu Teilnehmer C auf?

Sehr gute Frage - würde mich auch interessieren. Weiß ich aber leider nicht und Tracen kann ich dort leider auch nicht. Sind jedenfalls Avaya-Telefone (ja, ich weiß - genauer geht gerade leider nicht) und die Rufumleitung oder Weiterleitung ist direkt am Telefon gesetzt.

Das ist keine "Totmannschaltung" sondern ein regulärer Session Refresh, wie in RFC4028 beschrieben.

Wirkt aber leider genauso. Weil offensichtlich irgendeiner der refreshs auf dem gesamten Weg den Bach runter geht. Fragt sich nur, wo. In den CDRs der abgebrochenen Calls ist immer der Trunk bei mir (=> die Telekom) als Initiator des Abbruchs hinterlegt. Trace habe ich ja leider noch keinen von den abgebrochenen Gesprächen.

Welcher Session-Refresh Parameter werden denn beim Aufbau der Session ausgehandelt? Sprich welcher UA ist der Refresher?

Telekom ist in meinen Versuchen zum Nachstellen bei beiden Legs der Refresher.

Hier wird offenbar ein Session-Timer von 900s ausgehandelt. Gemäß RFC4028 wird dann regulär zur Hälfte der Timer-Zeit ein Refresh vorgenommen => 7,5 Minuten.

Nicht wirklich. Die handeln sowohl im ausgehenden als auch im eingehenden Call 1800s (in Folge 15 Minuten) aus:

Ausgehender Call (da findet der Refresh ja alle 15 Minuten statt / aber doppelt - sowohl via update als auch ReInvite):
200 OK der Telekom nachdem TN B abgenommen hat:

Session-Expires: 1800;refresher=uas

Eingehender Call über die Umleitung via Telekom AllIP zurück zu mir (alle 7,5 Minuten nur via ReInvite):
INVITE der Telekom AllIP:

Min-Se: 900
Session-Expires: 1800

Antwort von Asterisk im 200 OK

Session-Expires: 1800;refresher=uac

=> Ich sehe da keinen Grund, alle 7,5 Minuten zu refreshen. Irgendwer grätscht da dazwischen.

Was mir gerade auch auffällt: Von der Telekom kommt grundsätzlich der Min-Se - Parameter, obwohl der gemäß RFC Min-SE heißt. Naja, Stört ja sonst auch nicht (kommt bei jedem eingehenden Call so und es werden immer alle 15 Minuten via update refreshs durchgeführt).

 

[gehtdoch]

Ich konnte mittlerweile noch weitere Fälle auswerten. Das Problem lässt sich nun soweit eingrenzen / beschreiben:

1. Betroffen sind Calls zu sip-trunk.telekom.de / unabhängig vom Zielkunden (zumindest meinen) - tritt also bei unterschiedlichen Kunden auf. Ich habe keine sip-trunk destination, bei der das Problem nicht irgendwann auftritt.
2. Das Sessionhandling ist pro konkreter Destination und pro Call(!) völlig zufällig (auch innerhalb des selben Calls). Mal via ReInvite und Update gleichzeitig, dann nur Update oder nur ReInvite pro Sessionhandling (alle 15 Minuten). Das Sessionhandling kommt zu 100% von der Telekom bei mir an (asterisk macht an dieser Stelle nichts - antwortet nur, was auch immer fehlerfrei bestätigt wird).
3. Wenn Abbrüche auftreten, dann nur beim ersten Refresh nach 15 Minuten. Wenn man den überlebt hat, scheint es bei den folgenden Refreshs keine Probleme mehr zu geben.
4. Wenn man direkt nach dem Abbruch die exakt gleiche Nummer wieder anruft, funktioniert es plötzlich problemlos. Also keine Abhängigkeit zu Rufumleitung vorhanden oder nicht (wie ursprünglich angenommen) - die ändert sich nämlich nicht innerhalb von ein paar Sekunden von einem Call zum anderen.
5. Paketverlust (zumindest zu mir) schließe ich grundsätzlich aus, da ich via tcp/tls unterwegs bin. Außerdem müsste das dann ja auch zu anderen Providern auftreten.
   

Mein Fazit (ausgehende Calls zum sip-trunk):
Ob ein Call abbricht oder nicht, ist reiner Zufall, weil sich Telekom und Telekom sip-trunk in Sachen Sessionhandling einfach nicht einigen können. Mal so - mal so. Hier treten aus meiner Sicht Raceconditions auf. Es wäre schön, wenn sich da mal einer der Telekom darum kümmern könnte und das Sessionhandling zwischen den beiden Systemen prüfen und sicherstellen könnte.

(eingehende Calls vom sip-trunk)
Bei eingehenden Calls hatte ich bisher noch keine Probleme - allerdings treten auch hier wirre Sessionhandlings auf. Innerhalb des gleichen Gesprächs mal Update/ReInivte, dann nur ReInvite. Scheint wohl nur Zufall zu sein, dass das an dieser Stelle bisher noch zu keinen Abbrüchen geführt hat.

 

[Meester Proper]

Schick mir per PN, Quell- und Zielrufnummer, sowie den genauen Zeitpunkt, nicht älter als sieben Tage.

Ich schaue dann mal, wo der Fehler liegt.

 

[gehtdoch]

Du hast Post. Danke!

 

[Meester Proper]

Das Szenario:
Anrufer ist FreePBX am Retail IP-Anschluss, der einen DLAN SIP-Trunk Anschluss anruft.
Am SIP-Trunk Anschluss wird ein AudioCodes M800C und offensichtlich im LAN dahinter eine ALE OmniPCX Enterprise PBX betrieben.
Anrufer und Zielteilnehmer nutzen TLS und SRTP.

Zum fehlgeschlagenen Anruf / Abbruch beim Session-Refresh:
Der Anrufer sendet ein INVITE mit folgenden Angaben zum Aufbau der Session:

INVITE sip:[email protected]-online.de SIP/2.0
[...]
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: replaces, norefersub
User-Agent: FPBX-15.0.16.75(18.0.0)
Content-Type: application/sdp
Content-Length: 474

v=0
o=- 1654236634 1654236636 IN IP4 xxx.xxx.xxx.xxx
s=Asterisk
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 10050 RTP/SAVP 8 0 101
a=3ge2ae:requested
a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:sINRRwRMn51l7wpO6W+LJ19Iqga2X4dVREZ5/TJDakKnFEr2komdXZStQzDwEw==
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:CYJ1982OvfEherHEAoDRvKIJFe8CZXvB+gS1ZaHW
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

Der Ruf wird schließlich wie folgt akzeptiert / geht in die Late/Confirmed-Phase über:
SIP/2.0 200 OK
[...]
Session-Expires: 1800;refresher=uas
Supported: timer
Supported: 100rel
Supported: path
Content-Type: application/sdp
Content-Length: 310
Session-ID: a632f767725fc1635b5cdffb2f0373f8
Authentication-Info: qop=auth,rspauth="472b5c4d9bd2d2f9ff36fbf553566ef2",cnonce="7f658ffa84ae48d287c3b9263532c28b",nc=00000001
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 801726786476394 1343233710 IN IP4 217.0.20.195
s=on transit
c=IN IP4 217.0.135.5
t=0 0
m=audio 30030 RTP/SAVP 8 101
a=sendrecv
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:30
a=rtpmap:101 telephone-event/8000
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:9Z6YYjBMBrtdb3OzPp7d19BmSiuEDd6GJneuhPZ4

=> Es wurde ein Session-Timer mit 1800s festgelegt, der vom UAS, also dem Zielteilnehmer refresht wird.

Nach 15 Minuten sendet dann der Zielteilnehmer / AudioCodes M800 ein Re-INVITE.
Ich vermute, dass die OXE hinter dem SBC das Session-Refresh macht und kein UPDATE unterstützt.

INVITE sip:[email protected]:5061;transport=tcp SIP/2.0
Max-Forwards: 61
Min-Se: 900
Session-Expires: 1800;refresher=uac
Supported: timer
Supported: 100rel
Supported: path
Content-Type: application/sdp
Content-Length: 310
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 801726786476394 1343233710 IN IP4 217.0.20.195
s=on transit
c=IN IP4 217.0.135.5
t=0 0
m=audio 30030 RTP/SAVP 8 101
a=sendrecv
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:30
a=rtpmap:101 telephone-event/8000
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:9Z6YYjBMBrtdb3OzPp7d19BmSiuEDd6GJneuhPZ4

Der FreePBX- / A-Teilnehmer antwortet nun folgendes:

SIP/2.0 200 OK
[...]
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-15.0.16.75(18.0.0)
Content-Type: application/sdp
Content-Length: 450

v=0
o=- 1654236634 1654236636 IN IP4 xxx.xxx.xxx.xxx
s=Asterisk
c=IN IP4 xxx.xxx.xxx.xxx
t=0 0
m=audio 10050 RTP/SAVP 8 101
a=3ge2ae:requested
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:CYJ1982OvfEherHEAoDRvKIJFe8CZXvB+gS1ZaHW
a=crypto:1 AES_256_CM_HMAC_SHA1_80 inline:sINRRwRMn51l7wpO6W+LJ19Iqga2X4dVREZ5/TJDakKnFEr2komdXZStQzDwEw==
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

Hier liegt das Problem, die Session-Version wird nicht erhöht (im Vergleich zum initialen INVITE), die Session-Description ändert sich jedoch!
Im initialen INVITE heißt es: m=audio 10050 RTP/SAVP 8 0 101 - während es im 200 OK wie folgt heißt: m=audio 10050 RTP/SAVP 8 101
Dies verstößt gegen eine der fundamentalen Prinzipien des SDP Offer-Answer-Handling.

RFC3264, Abschnitt 8:
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.

=> Aus diesem Grund wird die Session ausgelöst!

 

[gehtdoch]

Absolut perfekte Analyse, @Meester Proper! Ganz herzlichen Dank!

Ich habe nun beispielhaft zwei andere Fälle, die ich hier habe, diesbezüglich analysiert - v.a. den Fall, der beim ersten Call abgebrochen ist - beim zweiten Call paar Minuten später aber nicht. Da, wo er nicht abgebrochen ist, wurde die SDP-Session-Version tatsächlich hochgezählt - während sie im Abbruchfall nicht hochgezählt wurde. Das wird jetzt spaßig, den "Blinker" in Asterisk zu finden. Solche Fehler liebe ich ganz besonders! Es gab da ja schonmal Probleme im Zusammenhang mit 116116 ... . Der Fix, den ich dafür damals gemacht habe, zieht ganz offensichtlich an dieser Stelle nicht. Irgendwie scheint da noch was anderes im Argen zu sein. Normalerweise zählt Asterisk die SDP-SessionID immer hoch (unabhängig davon, ob sich was an der Session Description geändert hat oder nicht).

Es ist dabei offensichtlich auch völlig irrelevant, ob da jetzt noch ein UPDATE mit im Boot ist oder nicht. Das ist wohl nur ein Nebenkriegsschauplatz. Der ReInvite kommt wohl vom TN B, der dann auch den Call beendet hat. Die Updates (wenn sie denn kommen, von der Telekom - warum die, falls ein ReInvite im Spiel ist, nicht immer kommen, ist mir allerdings noch schleierhaft. Ich hätte da ein Beispiel, falls es Dich interessiert).

Update 10.4.2021:
Das Problem mit dem unter bestimmten Umständen fehlenden Update der SDP Session Version ist nun offiziell und korrekt gefixt ab Version 18.3.0 und 16.17.0 (seit ca. 11.03.2021).

 

[Meester Proper]

Sofern das/die Beispiel/e innerhalb der letzten sieben Tage liegt/liegen, kannst du mir das gerne per PN zukommen lassen.

 

[gehtdoch]

Nein, die Beispiele mit update / reinvite oder nur eins von beidem wären vom 6.10. oder 14.10. - sind also zu alt. Ich warte mal ab, bis es aktuell mal wieder auftritt und melde mich dann!

 

[ChadTheMan]

Hallo,
ich besitze Telekom und habe Probleme manchmal das meine Spiele gefühlt drei Tage dauern um heruntergeladen zu werden obwohl ich ein W-LAN Verstärker habe und das Netz dann einfach random abstürzt. Habt ihr Tipps ich hatte auch Telekom informiert und sie meinten das alles wieder gut sei, wobei sie gar nichts unternommen haben um mir zu helfen. Brauche Hilfe?
LG
Chad

 

[Meester Proper]

Hast du testweise per Kabel getestet, um auszuschließen, dass das WLAN das Problem ist?

 

[gehtdoch]

Sofern das/die Beispiel/e innerhalb der letzten sieben Tage liegt/liegen, kannst du mir das gerne per PN zukommen lassen.

Hab Dir was zukommen lassen. Hat sich heute was ergeben. Bin auf das Ergebnis gespannt. Gab übrigens zwei Calls heute von exakt der gleichen Destination. Der erste zeigte dieses Verhalten nicht - im zweiten, den ich Dir genannt habe, kam es gleich öfter vor (auch beim ersten hätte es genügend Gelegenheiten gegeben ). Ach so, beide Calls liefen abgesehen von den abweichenden ReInvites problemlos - also kein Abbruch!

Was das SDP-Session-Thema angeht: da bin ich gerade dabei, einen anderen Code zum Anpassen der Session-ID zu testen. Hatte derzeit allerdings noch keine großen Testgelegenheiten.

Update:
Die 116116 ist leider keine Testnummer mehr wie früher, als man da am Anfang erstmal über einen ReInvite geschickt wurde beim Zugriff via Telekom. Gibt's da evtl. eine andere Nummer mittlerweile, die ein derartiges Verhalten aufweist und mit der man mal testen kann?

 

[Meester Proper]

Sorry, ich hatte viel zu tun und bin daher jetzt erst dazu gekommen.

Das Szenario:
Ein DLAN SIP-Trunk Anschluss ruft eine FreePBX am Retail IP-Anschluss an.
Am SIP-Trunk Anschluss wird ein AudioCodes M800C und offensichtlich im LAN dahinter eine ALE OmniPCX Enterprise PBX betrieben.
Anrufer und Zielteilnehmer nutzen TLS und SRTP.

Zum Anruf mit "doppeltem Session-Refresh":
Der Anrufer setzt einen Session-Timer auf, bei dem er selbst (UAC) als Refresher agiert.
Auf dem Weg zum B-Teilnehmer wird der Anrufer über einen IMS-Applikationsserver geführt, der eine Leg-weise Sessionüberwachung (je eines in Ursprung- und eines in Zielrichtung) vornimmt.
Da der Session Timer erst mit dem finalen 200 OK auf das INVITE aktiviert wird, kommt dieses auf dem Rückweg vom B- zum A-Teilnehmer zu erst am IMS-AS und erst später beim A-Teilnehmer an.

Nach 15 min wird zuerst vom IMS-AS der Session-Refresh Request in Richtung Zielteilnehmer (UPDATE) gesendet. Der A-Teilnehmer sendet kurz danach ein Re-INVITE als Session Refresh Request.
Hier kommt die Besonderheit zum Tragen: Auf der SIP-Trunk Plattform wird automatisch die Session Version im SDP hochgezählt. Dieses Feature wurde eingeführt, um ein anderes Client-Fehlverhalten zu mitigieren.
Regulär würde der IMS-AS den Session Refresh Request vom A-Teilnehmer nicht zum B-Teilnehmer weitersenden, aufgrund der erhöhten Session Version muss das INVITE jedoch weiter in Richtung B-Teilnehmer gesendet werden.
Aus diesem Grund bekommt der B-Teilnehmer je ein Session Refresh Request vom IMS-AS (UPDATE) und ein Session Refresh Request (INVITE) vom A-Teilnehmer.
Würde der A-Teilnehmer UPDATE als Session Refresh Request unterstützen, würde dies vom IMS-AS als Session Refresh Request erkannt werden.

Übrigens lässt sich das am A-Teilnehmer SBC als Session Refresh Request Interworking INVITE <-> UPDATE konfigurieren, dass dort UPDATE verwendet wird, nach außen auf dem Trunk.

 

[gehtdoch]

Super - Danke Meester Proper! Alles gut! Keine Eile!
Verstehe ich soweit.
Wobei hier die bei jedem ReInivte die ankommende Session-Version identisch ist (hat sich ja auch nichts geändert). So ganz klar ist mir das dann noch nicht, warum der ReInvite dann trotzdem durchgereicht wird, obwohl sich ja nichts geändert hat und der IMS-AS das ja auch erkannt hat (sonst hätte er ja die SDP-Session hochgezählt).

Wo Du jetzt aber für mich noch nicht eindeutig drauf eingegangen bist - das ist mir noch nicht so ganz klar:
Nach dem 2. Update / ReInvite-Vorgang (also zu Minute 45) z.B. erfolgt ja nur ein ReInvite-Vorgang ohne Update zuvor (wie später auch noch mal). Ich hätte jetzt erwartet, dass das Verhalten immer so ist, wie Du oben beschrieben hast - und nicht mal so - mal so. Der IMS-AS erkennt die ReInvites ja nicht als Mittel zum Session Refresh.

 

[Meester Proper]

Das ist ein guter Hinweis, dass sich auf dem Call-Leg zum Zielteilnehmer die Session Version nicht geändert hat. Ich kann nur mutmaßen, dass der IMS-AS vom Wunsch des A-Teilnehmers bzgl. einer aktuellen Session Description vom B-Teilnehmer ausgeht und daher das Re-Invite weiterschickt.

Ich habe mir den kompletten Call auch noch einmal angeschaut. Ich sehe dort immer UPDATE und Re-INVITE zum B-Teilnehmer, kann deine Anmerkung daher nicht nachvollziehen.

 

[gehtdoch]

Spannend. Dann siehst Du wahrscheinlich nicht den letzten Hop zwischen Mir und Dir. Hier ist definitiv folgendes zu sehen (Ausschnitt):

Bei Asterisk eingehender Call

INVITE CSeq 1

900s später
UPDATE CSeq 2
INVITE CSeq 3

900s später
UPDATE CSeq 4
INVITE CSeq 5

900s später
kein UPDATE
INVITE CSeq 6

900s später
UPDATE CSeq 7
INVITE CSeq 8

=> bei mir fehlen keine Pakete - sonst würde die CSeq nicht stimmen (passiert später noch zwei mal - nur ReInvite).