Trong thiết lập của tôi, tôi có một máy chủ tùy chỉnh trong xử lý đám mây âm thanh và video vì vậy tôi không cần (và không muốn) toàn bộ "tôi đang ở đâu và địa chỉ riêng tư và công cộng của tôi, v.v ..." quá trình khám phá. Về cơ bản tôi muốn cung cấp SDP và không quan tâm đến địa chỉ IP/cổng; đề nghị đó đi tới máy chủ, máy chủ chọn codec và nhận khóa SRTP và trả lời bằng câu trả lời SDP cho trình duyệt có chứa địa chỉ công khai, lựa chọn codec và khóa của nó. Lý tưởng nhất là trình duyệt bắt đầu gửi phương tiện đến máy chủ và máy chủ chỉ gửi phương tiện "ngang hàng" trở lại từ nơi nó đến (đường hầm sẽ quay trở lại thông qua bất kỳ thiết bị NAT thân thiện nào của UDP).Khi tạo một WebRTC PeerConnection tôi có thể bỏ qua quá trình khám phá ICE (STUN/TURN) không?
Tôi biết điều này là kỹ thuật có thể vì tôi đã làm điều này với máy khách Win32/OSX dành cho máy tính để bàn ... câu hỏi là, điều này có thể thực hiện với WebRTC và RTCPeerConnection không? Tôi đã thử một vài loại cấu hình, ví dụ: {} và { "iceServers": [] } nhưng nó vẫn có vẻ đi qua các vòng quay khám phá. Có lẽ các cách khác để tắt quá trình này không? Cảm ơn!
Cảm ơn câu trả lời và liên kết. Kiến trúc của tôi yêu cầu báo hiệu (SIP) trên TLS và SRTP được xác thực cho phương tiện. Tôi dự định sử dụng WebRTC và WebSockets qua HTTPS/TLS và yêu cầu SRTP được xác thực, vì vậy tôi không chắc tại sao tôi cần thêm kiểm tra ICE/STUN cho mục đích bảo mật ...? – mark
Sự cố bảo mật xảy ra khi thiết lập phiên truyền thông. Bạn có thể đọc tài liệu để biết thêm chi tiết, nhưng thực tế là bạn không thể bắt đầu phiên truyền thông với Chrome chỉ bằng cách sử dụng tiêu đề c = và m = SDP, như cũ "máy tính để bàn Win32/OSX dành cho máy tính để bàn". – nakib
không chính xác. Nếu bạn không cung cấp máy chủ STUN (hoặc TURN), sẽ không có kiểm tra STUN nào cả. Tuy nhiên, ICE vẫn sẽ xảy ra và sẽ thu thập và sử dụng các ứng viên chủ nhà (địa phương). –