需要澄清 Kurento 的 API 以将 webRTCEndpoint 连接到 RTPEndpoint
Need clarification on Kurento's API to connect webRTCEndpoint to RTPEndpoint
我正在尝试使用 Kurento 的 webRTCendpoint 到 RTPendpoint 的桥接。 webRTCendpoint 客户端是一个 Chrome 浏览器。 RTPendpoint 客户端是一个 SIP 服务器 (proxy/B2BUA)。这是我的基本代码或伪代码(我在我的应用程序服务器中使用 Kurento-client.js):
//On receipt of offer from the WebRTC Browser-Peer
mySignalling.on('sdpOffer', function(sdpOffer) { //Action starts!
//Create Mediapipeline so that endpoints can be created
kurentoClient.create('MediaPipeline', function(error, pipeline) {
pipeline.create('webRtcEndpoint', function(error, myWebrtcEndpoint) {
//Get ICE Candidates from webRTC endpoint to send to browser
mySignalling.on('candidate', function(candidate) {
myWebrtcEndpoint.addIceCandidate(candidate);
});
myWebrtcEndpoint.on('OnIceCandidate', function(event) {
var candidate = kurento.register.complexTypes.IceCandidate(event.candidate);
mySignalling.send(candidate); //Send ICE candidate to webRTC browser peer
});
pipeline.create('rtpEndpoint', function(error,myRtpEndpoint) {
myWebrtcEndpoint.connect(myrtpEndpoint,function(error){ });
myWebrtcEndpoint.processOffer(sdpOffer, function(error, sdpAnswer) {
mySignalling.send(sdpAnswer); //Send answersdp to browser
});
myRtpEndpoint.generateOffer(function(error){
myRtpEndpoint.getLocalSessionDescriptor(function(error, sdpRTP) {
mySignalling2.send(sdpRTP); //Send SDP to Asterisk as part of SIP INVITE
});
});
});
});
});
});
我有几个问题:
- 整体结构是否正确?
- webRTCEndpoint.gatherCandidates有什么用?文档说它必须在 processOffer 之后调用。为什么?它是如何连接到 addIceCandidate 方法的?
- RTPendpoint 已连接到 webrtcEndpoint,但如何控制 RTPEndpoint generateOffer 生成的 RTP 配置文件?我的意思是,例如,我如何从 RTPEndpoint 获得 RTP/AVPF 而不是 RTP/AVP?如果不是,并且 AVPF 必须映射到 AVP,Kurento 是否会在从 AVPF 桥接到 AVP 时处理 AVPF 中的“F”。
为简单起见,我没有添加错误处理、OnIceGatheringDone 事件处理、multiple-users/sessions 的规定等
另一方面,我正在应用服务器中构建自己的 SIP 请求并处理 SIP 响应。如果需要,我将更改 RTPEndpoint.generateOffer 生成的 SDP。当我克服这个最初的障碍时,就会达到那个点!
1) 看起来不错。如果您愿意,可以在创建 RtpEndpoint
之前完成 WebRtcEndpoint
协商。此外,您错过了对 gatherCandidates
的调用,这在您的下一个问题中有所涉及。
2) gatherCandidates
用于向 de WebRtcEndpoint 发出信号以开始收集 ICE 候选者。那是 trickle ICE,它是 ICE 协议的优化:候选人在被发现时发出,并发送给其他对等点进行探测。这加快了连接时间,因为可以在收集所有内容之前找到有效的候选对象(这可能需要 20 秒或更长时间)。 WebRtcEndpoint
需要将候选人发送到远程对等方,而从远程对等方接收到的候选人将使用 addIceCandidate
方法进行处理。如果您在处理报价或生成答案之前调用 gatherCandidates
,这些候选人将被添加到 SDP 报价或答案中,并且您将使用 Vanilla ICE。
3) 如果您打算将 RtpEndpoint 仅用于发射,我建议您提供一个带有您需要的选项的损坏的 SDP,并提供该端点进程。例如,如果您要发送到 Wowza,您可以修复 Wowza 媒体服务器期望 RTP 流的 IP 和端口。
我正在尝试使用 Kurento 的 webRTCendpoint 到 RTPendpoint 的桥接。 webRTCendpoint 客户端是一个 Chrome 浏览器。 RTPendpoint 客户端是一个 SIP 服务器 (proxy/B2BUA)。这是我的基本代码或伪代码(我在我的应用程序服务器中使用 Kurento-client.js):
//On receipt of offer from the WebRTC Browser-Peer
mySignalling.on('sdpOffer', function(sdpOffer) { //Action starts!
//Create Mediapipeline so that endpoints can be created
kurentoClient.create('MediaPipeline', function(error, pipeline) {
pipeline.create('webRtcEndpoint', function(error, myWebrtcEndpoint) {
//Get ICE Candidates from webRTC endpoint to send to browser
mySignalling.on('candidate', function(candidate) {
myWebrtcEndpoint.addIceCandidate(candidate);
});
myWebrtcEndpoint.on('OnIceCandidate', function(event) {
var candidate = kurento.register.complexTypes.IceCandidate(event.candidate);
mySignalling.send(candidate); //Send ICE candidate to webRTC browser peer
});
pipeline.create('rtpEndpoint', function(error,myRtpEndpoint) {
myWebrtcEndpoint.connect(myrtpEndpoint,function(error){ });
myWebrtcEndpoint.processOffer(sdpOffer, function(error, sdpAnswer) {
mySignalling.send(sdpAnswer); //Send answersdp to browser
});
myRtpEndpoint.generateOffer(function(error){
myRtpEndpoint.getLocalSessionDescriptor(function(error, sdpRTP) {
mySignalling2.send(sdpRTP); //Send SDP to Asterisk as part of SIP INVITE
});
});
});
});
});
});
我有几个问题:
- 整体结构是否正确?
- webRTCEndpoint.gatherCandidates有什么用?文档说它必须在 processOffer 之后调用。为什么?它是如何连接到 addIceCandidate 方法的?
- RTPendpoint 已连接到 webrtcEndpoint,但如何控制 RTPEndpoint generateOffer 生成的 RTP 配置文件?我的意思是,例如,我如何从 RTPEndpoint 获得 RTP/AVPF 而不是 RTP/AVP?如果不是,并且 AVPF 必须映射到 AVP,Kurento 是否会在从 AVPF 桥接到 AVP 时处理 AVPF 中的“F”。
为简单起见,我没有添加错误处理、OnIceGatheringDone 事件处理、multiple-users/sessions 的规定等
另一方面,我正在应用服务器中构建自己的 SIP 请求并处理 SIP 响应。如果需要,我将更改 RTPEndpoint.generateOffer 生成的 SDP。当我克服这个最初的障碍时,就会达到那个点!
1) 看起来不错。如果您愿意,可以在创建 RtpEndpoint
之前完成 WebRtcEndpoint
协商。此外,您错过了对 gatherCandidates
的调用,这在您的下一个问题中有所涉及。
2) gatherCandidates
用于向 de WebRtcEndpoint 发出信号以开始收集 ICE 候选者。那是 trickle ICE,它是 ICE 协议的优化:候选人在被发现时发出,并发送给其他对等点进行探测。这加快了连接时间,因为可以在收集所有内容之前找到有效的候选对象(这可能需要 20 秒或更长时间)。 WebRtcEndpoint
需要将候选人发送到远程对等方,而从远程对等方接收到的候选人将使用 addIceCandidate
方法进行处理。如果您在处理报价或生成答案之前调用 gatherCandidates
,这些候选人将被添加到 SDP 报价或答案中,并且您将使用 Vanilla ICE。
3) 如果您打算将 RtpEndpoint 仅用于发射,我建议您提供一个带有您需要的选项的损坏的 SDP,并提供该端点进程。例如,如果您要发送到 Wowza,您可以修复 Wowza 媒体服务器期望 RTP 流的 IP 和端口。