Jitsi generates a tcpType attribute for ssltcp candidates, but WebRTC libjingle rejects that attribute for "non-TCP" candidates:
07-29 12:04:22.548 2908-4704/live.attach.testcontainer E/libjingle: (webrtcsdp.cc:356): Failed to parse: "candidate:1 1 ssltcp 2130706431 192.168.0.5 4443 typ host tcptype passive generation 0". Reason: Invalid non-TCP candidate
07-29 12:04:22.548 2908-4708/live.attach.testcontainer E/PeerConnectionClient: Peerconnection error: setSDP error: SessionDescription is NULL.
Due to my understanding, an ssltcp candidate is not any different from a tcp candidate, so I'd assume jitsi is right and the candidate should contain the attribute. Can anybody confirm I'm right before I post an issue to webrtc?
Jitsi generates a tcpType attribute for ssltcp candidates, but WebRTC
libjingle rejects that attribute for "non-TCP" candidates:
We probably strip tcptype at some point in the javascript client (or earlier), since I don't see it in webrtc-internals.
07-29 12:04:22.548 2908-4704/live.attach.testcontainer E/libjingle:
(webrtcsdp.cc:356): Failed to parse: "candidate:1 1 ssltcp 2130706431
192.168.0.5 4443 typ host tcptype passive generation 0". Reason: Invalid
non-TCP candidate
07-29 12:04:22.548 2908-4708/live.attach.testcontainer
E/PeerConnectionClient: Peerconnection error: setSDP error:
SessionDescription is NULL.
Due to my understanding, an ssltcp candidate is not any different from a
tcp candidate, so I'd assume jitsi is right and the candidate should
contain the attribute. Can anybody confirm I'm right before I post an
issue to webrtc?
I don't know of any actual definition for "ssltcp", so I have no idea what is right. It makes sense to at least support it, but I don't see any gains unless you're using "so". It appears that it has been that way for a long time:
https://bugs.chromium.org/p/webrtc/issues/detail?id=2204#c18
Regards,
Boris
ยทยทยท
On 29/07/16 14:16, Oliver Hausler wrote: