Sự cần thiết cho SIP RE-INVITE liên quan đến ICE là gì?

Question

Tôi hiểu nhiều chi tiết tốt về các cú gọi lỗ hổng NAT, ICE và SIP VOIP. Tôi đã trả lời khá nhiều câu hỏi về SO về các chủ đề này. Bây giờ tôi có một câu hỏi.

Tôi đang cố gắng hiểu sự cần thiết của thông điệp RE-INVITE được ghi lại cho SIP + ICE sau khi cuộc gọi đã được thiết lập.

Giả sử cấu trúc liên kết của thiết bị VOIP tín hiệu qua SIP và sử dụng ICE (với STUN/TURN) để thiết lập kết nối phương tiện. Sau khi kiểm tra kết nối ICE được thực hiện, cả hai thiết bị đầu cuối phải xác định chắc chắn các cặp địa chỉ ứng cử viên tốt nhất (IP, cổng) và sẽ sẵn sàng truyền trực tuyến phương tiện theo cả hai hướng. Tuy nhiên, kinh nghiệm của tôi với SIP và nhiều tài liệu cho thấy rằng sau khi callee gửi thông báo 200 OK để cho biết anh ta đang ở trạng thái trả lời, người gọi được mong đợi gửi RE-INVITE với SDP chứa ứng cử viên địa chỉ cụ thể được chọn bằng cách kiểm tra kết nối.

Một số liên kết mô tả RE-INVITE với ICE là here và here (bước 8). Rosenberg's tutorial (trang 30) thảo luận rằng RE-INVITE "đảm bảo rằng các hộp trung gian có địa chỉ truyền thông chính xác". Tôi không chắc tại sao điều đó lại quan trọng.

Khi nhận được RE-INVITE, callee có phải định cấu hình lại ngăn xếp ICE của mình để chuyển đổi ổ cắm hoặc địa chỉ dựa trên SDP mới nhận được không? Hoặc là RE-INVITE chỉ là một hình thức giao thức để chính thức thừa nhận cuộc gọi đã được thiết lập? Nếu bước RE-INVITE bị bỏ qua và cả hai bên bắt đầu truyền phát trực tuyến, điều gì có thể xảy ra?

Lý do tôi hỏi là vì tôi đang khám phá sử dụng ICE qua dịch vụ báo hiệu không phải là SIP. Tôi đang cố gắng tìm hiểu xem RE-INVITE có cần được mô phỏng hay không.

Answer 1

Một ví dụ về hộp giữa, có thể quan tâm đến kết quả của thương lượng ICE là người quản lý băng thông.

Hãy tưởng tượng triển khai doanh nghiệp, với điểm cuối bên trong tường lửa của công ty và những người khác chuyển vùng xung quanh trên Internet hoặc sau tường lửa gia đình riêng. Việc triển khai cũng bao gồm một máy chủ TURN có thể truy cập công khai. Sau đó, hãy tưởng tượng một điểm cuối bên trong tường lửa của công ty thực hiện cuộc gọi. Nếu đích đến xảy ra có thể truy cập được trên cùng một mạng, cuộc gọi sẽ chuyển sang máy chủ lưu trữ và máy chủ TURN sẽ không được sử dụng (tức là các liên kết sẽ bị hủy cấp phát). Đây là mạng cục bộ và không cần áp đặt giới hạn băng thông. Mặt khác, nếu cuộc gọi đi đến điểm cuối chuyển vùng, thì máy chủ TURN sẽ tham gia và dữ liệu sẽ truyền qua tường lửa của công ty, thông qua những gì có thể là đường lên băng thông hạn chế. Chúng ta có thể tưởng tượng một số chính sách muốn hạn chế băng thông của cuộc gọi. Một cách để thực hiện nó là dành cho trình quản lý băng thông duy trì đường dẫn tín hiệu (sử dụng các tuyến đường ghi SIP) và xem xét SDP của bất kỳ INVITE nào, ghi lại giá trị băng thông tùy thuộc vào địa chỉ truyền thông.

Tôi tin rằng ý định chung là, rằng thiết bị cũ của loại đó, mà không phải là ICE nhận thức, nên tiếp tục làm việc trong môi trường hỗn hợp giới thiệu điểm cuối ICE. Để duy trì tính tương thích ngược này, ICE chỉ nên giới thiệu xử lý mới (kiểm tra STUN, v.v.), nhưng từ quan điểm của các yếu tố không nhận thức ICE, nó sẽ không loại bỏ bất kỳ quy tắc hiện hành nào (cần phải tái INVITE để thay đổi đích của luồng truyền thông).

Answer 2

Trong hướng dẫn của Rosenberg, tôi tin rằng INVITE được gửi đi bởi vì các socket được chọn bởi ICE khác với các cổng truyền thông và kết nối (m/c-line) của SDP gốc và cho bất kỳ phần tử mạng nào nằm giữa hai tác nhân người dùng để được thông báo về các ổ cắm thực tế sẽ được sử dụng RTP, một INVITE được gửi đi với (các) socket được chọn ICE trong các phương tiện và các đường kết nối của SDP.

Nếu các ổ cắm được chọn ICE giống với ổ cắm trong dòng SDP m/c của yêu cầu INVITE ban đầu thì sẽ không cần yêu cầu tái INVITE. Hoặc nếu bạn biết không có "hộp trung gian" cần được thông báo về các thay đổi đối với các ổ cắm RTP thì cũng sẽ không cần phải gửi lại INVITE.