All-IP/VoIP: SIP-Nachrichten werden nicht nochmal verschickt

Forum zu LANCOM Systems VoIP Router/Gateways und zur LANCOM VoIP Option

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

All-IP/VoIP: SIP-Nachrichten werden nicht nochmal verschickt

Beitrag von Jirka »

Hallo zusammen,

zwei All-IP-LANCOM-Router, Gerät Nr. 2 mit Firmware 10.12-RU6, Gerät Nr. 1 mit 9.24.0376, verbunden über eine VPN-Strecke von zwei anderen LANCOM-Routern. Gerät 1 registriert sich mit einer SIP-Trunk-Leitung an Gerät 2, wo ein SIP-Trunk-Benutzer eingerichtet ist. Gerät 1 möchte ein Telefongespräch initiieren und schickt an Gerät 2 ein INVITE. An Gerät 2 sieht das wie folgt aus:

Gerät 2:

15:12:37,997: <- INVITE (trifft in Gerät 2 ein)
15:12:38,005: -> Trying (ACHTUNG, wegen eines Paketverlustes kommt dieses Paket nicht bei Gerät 1 an)
15:12:38,006: -> Proxy Authentication Required (ACHTUNG, wegen eines Paketverlustes kommt dieses Paket nicht bei Gerät 1 an)
15:12:38,996: <- INVITE
15:12:40,999: <- INVITE
15:12:45,001: <- INVITE
15:12:49,001: <- INVITE
15:12:53,000: <- INVITE
15:12:57,001: <- INVITE
15:13:01,003: <- INVITE
15:13:02,226: <- Request Timeout
15:13:02,227: -> ACK

Frage: In Gerät 2 treffen 23 Sekunden lang immer wieder INVITEs ein, weil Gerät 1 die ersten beiden Antwortpakete wegen eines Paketverlustes nicht bekommen hat. Warum kommt Gerät 2 nicht einmal auf die Idee, die Pakete nochmals zu verschicken? Es sind UDP-Pakete, die können doch verlustig gehen, d. h. der SIP-Stack dahinter muss das abfangen, tut er aber anscheinend nicht.

Anschließend geht es sehr komisch weiter:

Gerät 1 hatte oben ein Request Timeout geschickt. Anschließend schickt es nun ein (neues?!) INVITE ohne SDP (!) und mit der gleichen Call-ID wie zuvor. Das sieht auf Gerät 2 so aus:

Gerät 2:

15:13:05,004: <- INVITE (ohne SDP)
15:13:05,011: -> Trying (kommt bei Gerät 1 auch an)
15:13:05,012: -> Proxy Authentication Required
15:13:05,060: <- ACK
15:13:05,066: <- INVITE (ohne SDP) (geändertes Nonce)
15:13:05,066: -> Trying
15:13:05,831: -> INVITE (ohne SDP) zur Telekom
15:13:05,863: <- Trying von der Telekom
15:13:08,751: <- Ringing von der Telekom
15:13:08,757: -> Ringing (zu Gerät 1)
15:13:13,581: <- OK von der Telekom (mit SDP)
15:13:13,591: -> OK (zu Gerät 1)
15:13:13,840: <- ACK (von Gerät 1)
15:13:13,848: -> ACK zur Telekom
15:13:13,883: <- BYE von der Telekom mit "X-TAS-Edge-Policies: send-pheader-policy=772"
...

Frage: Wieso kommt Gerät 1 auf die Idee, ein INVITE ohne SDP zu schicken?! Das kann doch nur schief gehen, oder?

Unterm Strich sind 35 Sekunden vergangen und das Telefonat konnte in der Zeit nicht zugestellt werden. Traces sind natürlich vorhanden, aber eigentlich steht alles hier. Ich wollte es mal übersichtlicher gestalten, deswegen ohne die konkreten Pakete.

Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: All-IP/VoIP: SIP-Nachrichten werden nicht nochmal versch

Beitrag von Jirka »

Hallo zusammen,

zu meinem hier aufgeführten Fall hat sich ja bisher niemand geäußert. Ein wenig schade, aber ich habe die Hoffnung, dass das noch passiert. Deswegen will ich hier auch noch einen umgekehrten Fall hinzufügen, wo der LANCOM-Router unbelehrbar immer schön weiter seine SIP-Packete verschickt, tagelang.

Drauf gestoßen bin ich eigentlich, weil ich ein SIP-Problem analysieren wollte, aber der Trace trotz Filterung irgendwie viele Pakete enthielt. Bei genauerem Hinsehen wurde ich stutzig und erinnerte mich sogar, sowas schon mal gesehen zu haben. Ich schaute dann erst mal etwas genauer, was da für Pakete hin- und hergehen und verstand es nicht so recht, schaute, ob aktive Telefonate laufen, aber das war nicht der Fall. Anhand der Rufnummer im VoIP-Paket und auf Nachfragen beim Anrufer kam Folgendes raus:

Der Anrufer (interne Rufnummer 33 und hier mit xyz als Display-Name und 3088888888 als externe Rufnummer anonymisiert; SIP-Benutzer am VCM) rief zweieinhalb Tage zuvor den Teilnehmer mit der hier anonymisierten Rufnummer 0302222222 an. Das Telefonat ging 5 Minuten und 1 Sekunde und wurde normal beendet. Der "Call" blieb nicht im LANCOM hängen, alles sieht - ohne den SIP-Trace zu betrachten - normal und gut aus. Im SIP-Trace zeigt sich jedoch, dass der LANCOM immer noch mit dem Telefonat beschäftigt ist, was längst vergessen ist:

Alle 4 Sekunden kommen im SIP-Trace folgende zwei Pakete (zu und vom Gigaset):

Code: Alles auswählen

[SIP-Packet] 2018/03/30 11:53:28,045  Devicetime: 2018/03/30 11:53:28,732 [PACKET] : 
Sending datagram with length 427 from 10.10.10.1:5060 to 10.10.10.33:5060 using UDP (Rtg-Tag:1)
BYE sip:33@10.10.10.33:5060 SIP/2.0\r\n
Via: SIP/2.0/UDP 10.10.10.1:5060;branch=z9hG4bK-3c01600d-def23957\r\n
From: <sip:0302222222@XYZNet;user=phone>;tag=-664446381--571214014\r\n
To: "xyz"<sip:33@XYZNet>;tag=3033966427\r\n
Call-ID: 1685201765@10_10_10_33\r\n
CSeq: 1 BYE\r\n
Max-Forwards: 70\r\n
Server: XYZNet-Router\r\n
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, PRACK\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2018/03/30 11:53:28,095  Devicetime: 2018/03/30 11:53:28,768 [PACKET] : 
Receiving datagram with length 347 from 10.10.10.33:5060 to 10.10.10.1:5060 using UDP (Rtg-Tag:1)
SIP/2.0 481 Call Leg/Transaction Does Not Exist\r\n
Via: SIP/2.0/UDP 10.10.10.1:5060;branch=z9hG4bK-3c01600d-def23957\r\n
From: <sip:0302222222@XYZNet;user=phone>;tag=-664446381--571214014\r\n
To: "xyz" <sip:33@XYZNet>;tag=3033966427\r\n
Call-ID: 1685201765@10_10_10_33\r\n
CSeq: 1 BYE\r\n
User-Agent: S850A GO/42.245.00.000.000\r\n
Content-Length: 0\r\n
\r\n
Und der LANCOM begreift anscheinend nicht, dass das Gigaset längst das Telefonat beendet hat und sich zwei Tage später daran auch nicht mehr erinnern kann, weil für das Gigaset das Telefonat beendet und damit abgeschlossen ist ("Call Leg/Transaction Does Not Exist"). Das Gigaset sagt also, dass diese Verbindung nicht (mehr) existiert. Keine 4 Sekunden später kommt aber das nächste BYE vom LANCOM...

Das war die interne Seite. Nach außen sieht es nicht besser aus, nur dass der Provider auf die Pakete vom LANCOM wohl mittlerweile gar nicht mehr antwortet. Alle 50 Sekunden sendet der LANCOM folgendes Paket an den Provider:

Code: Alles auswählen

[SIP-Packet] 2018/03/30 11:53:30,552  Devicetime: 2018/03/30 11:53:31,238 [PACKET] : 
Sending datagram with length 521 from 91.66.100.100:9552 to 83.169.182.129:5060 using UDP
SIP/2.0 408 Request Timeout\r\n
Via: SIP/2.0/UDP 83.169.182.129:5060;branch=z9hG4bKihtv4d3088qcf2pj52m0.1\r\n
From: <sip:0302222222@reg141.kabelphone.de;user=phone>;tag=SDf4gc999-c8d8b67f+1+4d360138+d9bbf83b\r\n
To: "xyz"<sip:3088888888@reg141.kabelphone.de;user=phone>;tag=-1207862998-136267509\r\n
Call-ID: 1764246913@00a05711aa2d\r\n
CSeq: 0 INVITE\r\n
User-Agent: S850A GO/42.245.00.000.000\r\n
Server: XYZNet-Router\r\n
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, SUBSCRIBE, NOTIFY, REFER, UPDATE, PRACK\r\n
Content-Length: 0\r\n
\r\n
Was auch immer - ich vermute einen Paketverlust - zu dem Problem geführt hat, der LANCOM hängt hier in einer Dauerschleife fest und das ist nicht gut und muss gefixt werden. Firmware ist 9.24.0376.

Vielen Dank und viele Grüße,
Jirka
Antworten