I am attempting to use Kurento\'s bridging of webRTCendpoint to RTPendpoint. The webRTCendpoint client is a Chrome browser. The RTPendpoint client is a SIP server (proxy/B2B
1) It looks fine. You can finish the WebRtcEndpoint
negotiation before creating the RtpEndpoint
, if you'd like. Also, you're missing the call to gatherCandidates
, which is covered in your next question.
2) gatherCandidates
is used to signal de WebRtcEndpoint to start harvesting ICE candidates. That's trickle ICE, and it's an optimisation of the ICE protocol: candidates are emitted when discovered, and sent to the other peer for probing. This speeds up connection times, as a valid candidate can be found before all are harvested (which can take up to 20 seconds or more). The WebRtcEndpoint
needs to send the candidates to the remote peer, while the candidates received from the remote peer are processed with the addIceCandidate
method. If you call gatherCandidates
before processing the offer or generating the answer, those candidates will be added to the SDP offer or answer, and you'll be using Vanilla ICE.
3) If you are going to use the RtpEndpoint for emitting only, I'd recommend providing a mangled SDP with the options you need, and having the endpoint process that offer. If you are going to send to Wowza, for instance, you can fix the IP and port where the Wowza Media Server expects the RTP flow.