Closed duhoobo closed 4 years ago
You are correct there isn't currently any specific code for ICE Lite, I need to read up on the subject.
For your specific use case, to be clear: the gateway (ice lite) is offering the SDP to aioice?
Some news here. My scenario is as follows:
aiortc
that becomes the SDP offerer. In this case everything works without any change.
aiortc
becomes ICE controlling and, hence, DTLS server.aiortc
that becomes the SDP answerer. In this case some tricks must be done for it to work:
aiortc
does not understand ICE Lite so it insists in sending Binding requests with ICE_CONTROLLING
flag.aiortc
changes its ICE role and becomes ICE controlling.aiortc
started as ICE controlled it assumed that it should be DTLS server, and it remains being DTLS server after switching to ICE controlling.OK, if I understand correctly there is no issue with aioice
after all: it's an ICE full agent, and behaving correctly right? If so let's move the conversation back to aiortc
.
Let's say it works because we figured out the DTLS role that aiortc assumes regardless it's SDP offerer or SDP answered :)
OK I think this issue can be closed: aioice should now interop correctly with an ICE Lite peer. The only issue I found was that we always used agressive nomination. If you set connection.remote_is_lite
, aioice will now use regular nomination.
RFC 5245 is supported according to README, I thought ICE lite implementation was supported as well.
I write a demo running behind a NAT, trying to make a connection with WebRTC gateway which employs ICE lite implemetation.
The demo won't take a role as "controlling agent" while gateway as initiator (OFFERing sdp). This behavior seems not compatible with RFC 5245.
RFC 5245, 2.7. Lite Implementations