Gesprächsabbrüche bei Sip-Trunk Telekom mit vorgeschaltetem Router (vorgeschaltetes Gerät mit NAT): Unterschied zwischen den Versionen

Aus bintec elmeg Support-Wiki / FAQ

Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „Häufig werden uns sporadische Gesprächsabbrüche geschildert, bei denen die Ursache nur schwer nachvollziehbar ist. Um eine Nachweisbarkeit des Verhaltens z…“)
 
Zeile 1: Zeile 1:
 
Häufig werden uns sporadische Gesprächsabbrüche geschildert, bei denen die Ursache nur schwer nachvollziehbar ist.
 
Häufig werden uns sporadische Gesprächsabbrüche geschildert, bei denen die Ursache nur schwer nachvollziehbar ist.
 +
  
 
Um eine Nachweisbarkeit des Verhaltens zu bekommen wird oft ein Mitschnitt des Netzwerkdatenstroms zwingend notwendig.
 
Um eine Nachweisbarkeit des Verhaltens zu bekommen wird oft ein Mitschnitt des Netzwerkdatenstroms zwingend notwendig.
 +
 +
 
Die Herangehensweise beschreiben wir unter dem Suchwort pcap in einer andern Knowledge Base/FAQ.
 
Die Herangehensweise beschreiben wir unter dem Suchwort pcap in einer andern Knowledge Base/FAQ.
  
 
In diesem Fall liegen folgende Gegebenheiten vor:
 
In diesem Fall liegen folgende Gegebenheiten vor:
Internet /VoIP - SIP Provider   ->  Router mit NAT/(Grenzrouter)   ->   VoIP basiertes TK - System  
+
 
 +
 
 +
Internet /VoIP - SIP Provider   ->  Router mit NAT/(Grenzrouter)   ->   VoIP basiertes TK - System
  
 
Das Netzwerkprotokoll - Wireshark zeigt folgenden, für das Verhalten typischen SIP-Flow auf:
 
Das Netzwerkprotokoll - Wireshark zeigt folgenden, für das Verhalten typischen SIP-Flow auf:
  
  
VoIP Provider                                                               TK-System  
+
VoIP Provider                                            TK-System
Port 5060                                                                      z.B. Port 1129    
+
Port 5060                                                              z.B. Port 1129
  
5060                                 Invite  ->                             1129 SIP Invite From: ...  
+
5060                                 Invite  ->                     1129 SIP Invite From: ...
5060                       <-  180 Ringing                             1129 SIP Status 180 Ringing
+
5060                       <-  180 Ringing                     1129 SIP Status 180 Ringing
5060                       <- 200 OK Telephone event       1129 SIP Status 200 OK
+
5060                       <- 200 OK Telephone event       1129 SIP Status 200 OK5060                                 ACK  ->                                 1129 Request INVITE ACK
5060                                 ACK  ->                                 1129 Request INVITE ACK
+
5060                       <- Update                                      1130 Sip Update from 5060                         403 Forbidden Request  ->       1130 SIP Status 403 Forbidden
5060                       <- Update                                      1130 Sip Update from  
+
5060                       <- BYE                                             1130 Request BYE
5060                         403 Forbidden Request  ->       1130 SIP Status 403 Forbidden
 
5060                       <- BYE                                             1130 Request BYE  
 
  
  
 
Hier stellt sich die Frage, warum ändert sich der Port 1129 auf 1130 und warum wird ein Update gesendet, obwohl die Verbindung unverändert - erfolgreich besteht?
 
Hier stellt sich die Frage, warum ändert sich der Port 1129 auf 1130 und warum wird ein Update gesendet, obwohl die Verbindung unverändert - erfolgreich besteht?
 +
 +
 
Die Ursache liegt zum Teil am vorgeschalteten Router - 'hier ist NAT im Spiel ...'
 
Die Ursache liegt zum Teil am vorgeschalteten Router - 'hier ist NAT im Spiel ...'
  
Man kann dieses bei der Auswertung des Netzwerkprotokolls daran erkennen, dass die beteiligte IP-Adresse eine private Adresse ist z.B.: (192.168.49.xxx) und dass in den 'Responses (Antwort) auf unsere 'Requests' (Anfrage) im 'Via' des Wireshark Protokolls folgendes steht:  
+
Man kann dieses bei der Auswertung des Netzwerkprotokolls daran erkennen, dass die beteiligte IP-Adresse eine private Adresse ist z.B.: (192.168.49.xxx) und dass in den 'Responses (Antwort) auf unsere 'Requests' (Anfrage) im 'Via' des Wireshark Protokolls folgendes steht:
 +
 
 +
 
 
Via: SIP/2.0/TCP
 
Via: SIP/2.0/TCP
 +
 +
 
z.B.: 192.168.49.xxx:5060;rport=xxxxx; received= z.B.:80.151.219.xxx; branch=xxxxE802CBBA383710AC603170170xxxxx
 
z.B.: 192.168.49.xxx:5060;rport=xxxxx; received= z.B.:80.151.219.xxx; branch=xxxxE802CBBA383710AC603170170xxxxx
  
 
Um dieses Verhalten zu verhindern, kann folgendes in den Einstellungen des VoiP-Kontos in der be.IP/Hybird angepasst werden:
 
Um dieses Verhalten zu verhindern, kann folgendes in den Einstellungen des VoiP-Kontos in der be.IP/Hybird angepasst werden:
 +
 +
 
- einen STUN-Server konfigurieren (z.B. bei der Telekom    stun.t-online.de )
 
- einen STUN-Server konfigurieren (z.B. bei der Telekom    stun.t-online.de )
 +
 +
 
- unter erweitert wird "Vorgeschaltetes Gerät mit NAT" aktiviert - damit senden wir periodisch immer wieder Dummy-Pakete um das NAT offen zu halten.
 
- unter erweitert wird "Vorgeschaltetes Gerät mit NAT" aktiviert - damit senden wir periodisch immer wieder Dummy-Pakete um das NAT offen zu halten.
  
 
Zur Erklärung - wie kommt es zu so einem Verhalten?
 
Zur Erklärung - wie kommt es zu so einem Verhalten?
 +
 +
 
In dem eingehenden INVITE der Gegenstelle steht üblicherweise, dass diese die "Session-Timer" unterstützen, - sowie im "Allow", dass auch "UPDATE" erlaubt ist!
 
In dem eingehenden INVITE der Gegenstelle steht üblicherweise, dass diese die "Session-Timer" unterstützen, - sowie im "Allow", dass auch "UPDATE" erlaubt ist!
 +
 +
 
Daher senden wir periodisch (wenn ausgehandelt) ein UPDATE in Richtung des Netzbetreibers.
 
Daher senden wir periodisch (wenn ausgehandelt) ein UPDATE in Richtung des Netzbetreibers.
 +
 +
 
Nun kann (wird) es aber sein, dass inzwischen das 'NAT-Binding' im vorgeschalteten Router abgelaufen ist und die Gegenstelle das UPDATE von einer 'vermeintlich' anderen Gegenstelle bekommt.
 
Nun kann (wird) es aber sein, dass inzwischen das 'NAT-Binding' im vorgeschalteten Router abgelaufen ist und die Gegenstelle das UPDATE von einer 'vermeintlich' anderen Gegenstelle bekommt.
 +
 +
 
Anderer Port wegen neuem NAT - im Beispiel erfolgt der Wechsel von Port 1129 auf 1130.
 
Anderer Port wegen neuem NAT - im Beispiel erfolgt der Wechsel von Port 1129 auf 1130.
 +
 +
 
Voraussichtlich wird das UPDATE deshalb vom Provider abgelehnt.
 
Voraussichtlich wird das UPDATE deshalb vom Provider abgelehnt.
  
  
 
Stand: Apr. 2019
 
Stand: Apr. 2019
 +
 +
 
Produkt: be.IP Familie und Hybird
 
Produkt: be.IP Familie und Hybird
 +
 +
 
Version: alle
 
Version: alle
  
 
T.St. 2019
 
T.St. 2019

Version vom 15. April 2019, 10:30 Uhr

Häufig werden uns sporadische Gesprächsabbrüche geschildert, bei denen die Ursache nur schwer nachvollziehbar ist.


Um eine Nachweisbarkeit des Verhaltens zu bekommen wird oft ein Mitschnitt des Netzwerkdatenstroms zwingend notwendig.


Die Herangehensweise beschreiben wir unter dem Suchwort pcap in einer andern Knowledge Base/FAQ.

In diesem Fall liegen folgende Gegebenheiten vor:


Internet /VoIP - SIP Provider   ->  Router mit NAT/(Grenzrouter)   ->   VoIP basiertes TK - System

Das Netzwerkprotokoll - Wireshark zeigt folgenden, für das Verhalten typischen SIP-Flow auf:


VoIP Provider                                            TK-System Port 5060                                                              z.B. Port 1129

5060                                 Invite  ->                     1129 SIP Invite From: ... 5060                       <-  180 Ringing                     1129 SIP Status 180 Ringing 5060                       <- 200 OK Telephone event       1129 SIP Status 200 OK5060                                 ACK  ->                                 1129 Request INVITE ACK 5060                       <- Update                                      1130 Sip Update from 5060                         403 Forbidden Request  ->       1130 SIP Status 403 Forbidden 5060                       <- BYE                                             1130 Request BYE


Hier stellt sich die Frage, warum ändert sich der Port 1129 auf 1130 und warum wird ein Update gesendet, obwohl die Verbindung unverändert - erfolgreich besteht?


Die Ursache liegt zum Teil am vorgeschalteten Router - 'hier ist NAT im Spiel ...'

Man kann dieses bei der Auswertung des Netzwerkprotokolls daran erkennen, dass die beteiligte IP-Adresse eine private Adresse ist z.B.: (192.168.49.xxx) und dass in den 'Responses (Antwort) auf unsere 'Requests' (Anfrage) im 'Via' des Wireshark Protokolls folgendes steht:


Via: SIP/2.0/TCP


z.B.: 192.168.49.xxx:5060;rport=xxxxx; received= z.B.:80.151.219.xxx; branch=xxxxE802CBBA383710AC603170170xxxxx

Um dieses Verhalten zu verhindern, kann folgendes in den Einstellungen des VoiP-Kontos in der be.IP/Hybird angepasst werden:


- einen STUN-Server konfigurieren (z.B. bei der Telekom    stun.t-online.de )


- unter erweitert wird "Vorgeschaltetes Gerät mit NAT" aktiviert - damit senden wir periodisch immer wieder Dummy-Pakete um das NAT offen zu halten.

Zur Erklärung - wie kommt es zu so einem Verhalten?


In dem eingehenden INVITE der Gegenstelle steht üblicherweise, dass diese die "Session-Timer" unterstützen, - sowie im "Allow", dass auch "UPDATE" erlaubt ist!


Daher senden wir periodisch (wenn ausgehandelt) ein UPDATE in Richtung des Netzbetreibers.


Nun kann (wird) es aber sein, dass inzwischen das 'NAT-Binding' im vorgeschalteten Router abgelaufen ist und die Gegenstelle das UPDATE von einer 'vermeintlich' anderen Gegenstelle bekommt.


Anderer Port wegen neuem NAT - im Beispiel erfolgt der Wechsel von Port 1129 auf 1130.


Voraussichtlich wird das UPDATE deshalb vom Provider abgelehnt.


Stand: Apr. 2019


Produkt: be.IP Familie und Hybird


Version: alle

T.St. 2019