Jaka jest potrzeba SIP RE-INVITE w odniesieniu do ICE?

Question

Rozumiem wiele drobnych szczegółów połączeń dziurkowania NAT, ICE i SIP VOIP. Odpowiedziałem na kilka pytań dotyczących SO na te tematy. Teraz mam pytanie.

Próbuję zrozumieć potrzebę wiadomości RE-INVITE, która jest udokumentowana dla SIP + ICE po nawiązaniu połączenia.

Założenie topologii urządzeń VoIP, które sygnalizują SIP i używają ICE (z STUN/TURN) do ustanawiania łączności z mediami. Po przeprowadzeniu sprawdzania łączności ICE oba punkty końcowe powinny ustalić najlepsze pary kandydatów na adresy (adres IP, port) i powinny być gotowe do strumieniowego przesyłania multimediów w obu kierunkach.

Ale moje doświadczenie z SIP i dużą ilością dokumentacji sugeruje, że po wysłaniu przez callee komunikatu 200 OK, aby wskazać, że jest on w stanie odebranym, osoba dzwoniąca ma oczekiwać, że wyśle ​​RE-INVITE z SDP zawierającą wybranego kandydata na adres przez kontrolę łączności.

Niektóre linki opisujące RE-INVITE z ICE to here i here (krok 8). Rosenberg's tutorial (strona 30) mówi, że RE-INVITE "zapewnia, że ​​Middlebox ma prawidłowy adres medialny". Nie jestem pewien, dlaczego to jest ważne.

Po otrzymaniu RE-INVITE, czy spodziewany jest rekonfigurować swój stos ICE, aby przełączać gniazda lub adresy na podstawie otrzymanego nowego SDP? Czy też RE-INVITE jest formalnością protokołu, aby formalnie potwierdzić, że połączenie zostało ustanowione? Jeśli krok RE-INVITE został pominięty i obie strony zaczęły strumieniować multimedia, co mogło pójść nie tak?

Powodem, dla którego pytam, jest to, że badam używanie Lodu przez usługę sygnalizacji, która nie jest SIP. Próbuję dowiedzieć się, czy RE-INVITE musi być emulowany.

Answer 1

Jednym z przykładów middleboksa, który może być zainteresowany wynikiem negocjacji ICE, jest menedżer przepustowości.

Wyobraź sobie wdrożenie korporacyjne z punktami końcowymi wewnątrz korporacyjnej zapory sieciowej i innymi urządzeniami mobilnymi w Internecie lub za prywatnymi domowymi zaporami ogniowymi. Wdrożenie obejmuje również publiczny serwer TURN. Następnie wyobraźmy sobie punkt końcowy wewnątrz zapory korporacyjnej wykonującej połączenie. Jeśli miejsce docelowe stanie się osiągalne w tej samej sieci, połączenie przejdzie do hosta, a serwer TURN nie zostanie użyty (tzn. Powiązania zostaną wycofane). Jest to sieć lokalna i nie należy nakładać ograniczeń przepustowości. Z drugiej strony, jeśli połączenie wychodzi do roamingowego punktu końcowego, wtedy serwer TURN zostanie włączony, a dane przepłyną przez korporacyjną zaporę ogniową, przez co prawdopodobnie jest łącze o ograniczonej przepustowości. Możemy sobie wyobrazić politykę, która będzie ograniczać przepustowość połączenia. Jednym ze sposobów jest pozostawienie menedżera przepustowości na ścieżce sygnalizacyjnej (z wykorzystaniem tras rekordów SIP) i przyjrzenie się SDP każdego INVITE przechodzącego przez ponowne wpisywanie wartości przepustowości w zależności od adresów mediów.

Sądzę, że ogólnym zamiarem było, aby starszy sprzęt tego typu, który nie jest zgodny z ICE, powinien działać w środowisku mieszanym, wprowadzając punkty końcowe ICE. Aby zachować kompatybilność wsteczną, ICE powinien wprowadzać tylko nowe przetwarzanie (sprawdzanie STUN itp.), Ale z punktu widzenia elementów nie posiadających certyfikatu ICE nie powinien usuwać żadnych istniejących reguł (wciąż potrzebne są REWIZJA, aby zmienić miejsce docelowe strumienia medialnego).

Answer 2

W samouczku Rosenberga wierzę, że REWIZJA jest wysyłana, ponieważ gniazda wybrane przez ICE różnią się od tych w mediach i połączeniach (linie m/c) oryginalnego SDP ORAZ w przypadku jakichkolwiek elementów sieci, które znajdują się pomiędzy dwoma agentami użytkownika, którzy mają być informowani o rzeczywistych gniazdach, które będą używane RTP, a re-INVITE jest wysyłany z wybranymi gniazdami ICE w mediach i liniach połączeń SDP.

Jeśli wybrane gniazda ICE były takie same, jak te w oryginalnych liniach m/c SDP żądania INVITE, wówczas nie byłoby potrzeby ponownego żądania INVITE. Lub, jeśli wiesz, że nie ma żadnych "skrzynek pośrednich", które muszą być poinformowane o zmianach w gniazdach RTP, nie byłoby również potrzeby wysyłania REWIZYJNEGO.