0

ICE protocol was updated in RFC 8445. ICE lite predates that RFC. The details on ICE Lite in RFC 8445 is provided in Appendix A. It is very sketchy. However, way back in 2007, an attempt was made to formalize what ICE Lite was. That was in this draft RFC. It is fairly descriptive but some of the statements conflict those in RFC 8445. For example, RFC 8445 does allow for both peers to be ICE LITE while the draft document suggests otherwise.

Can someone point out the exceptions or corrections in the draft RFC on ICE LITE which will make it compatible with RFC 8445? Or point to a document that describes ICE LITE in more detail that the description in RFC 8445?

I am NOT using libnice but as there is no relevant tag on ICE, I used libnice hoping that users of libnice will have some info.

Community
  • 1
  • 1
asinix
  • 966
  • 1
  • 9
  • 22

1 Answers1

2

pion/ice has an option for ICE Lite. I did some things via trial and error, but here is what I learned along the way.

From RFC 8445 6.1.1. Determining Role

   Both lite:  The initiating agent that started the ICE processing MUST
      take the controlling role, and the other MUST take the controlled
      role.  In this case, no connectivity checks are ever sent.
      Rather, once the candidates are exchanged, each agent performs the
      processing described in Section 8 without connectivity checks.  It
      is possible that both agents will believe they are controlled or
      controlling.  In the latter case, the conflict is resolved through
      glare detection capabilities in the signaling protocol enabling
      the candidate exchange.  The state of ICE processing for each data
      stream is considered to be Running, and the state of ICE overall
      is Running.

I haven't found an extensive single place to learn about ICE Lite. But you can look at how pion/ice behaves, and happy to answer more individual questions!

Sean DuBois
  • 3,972
  • 1
  • 11
  • 22
  • I think that this conflicts with the need for username and short-term credentials (for connectivity check) as explained in Appendix B.4. If no connectivity check is done in the situation explained in this section, ICE will fail. I may be wrong. I will take you up on your offer to answer specific questions. – asinix Mar 09 '20 at 06:22
  • STUN RFC 5389 - Section 15.4 Message Integrity Attribute refers to the use of SHA1 only. However, when I was perusing the source code of CoTurn, I see options to use SHA256, SHA384, etc. As the use of SHA is purely for integrity and not security, I think SHA1 would suffice. Is there any RFC that updates this spec to enable the use of SHA256, etc. for message integrity attribute in STUN? – asinix Mar 10 '20 at 13:24
  • Sorry missed these! I am not aware of any RFCs that updated it. If you get a chance I would reach out on the Pion Slack https://pion.ly/slack I am there 24/7 and happy to talk deep WebRTC stuff! I am trying to use SO more though. – Sean DuBois Mar 21 '20 at 23:33
  • I am trying to implement WebRTC in pure C. Implementing all the components is a very good learning exercise. I will be following Pion more closely. Unfortunately I am not familiar with Go but will start learning soon... – asinix Mar 23 '20 at 06:22
  • AWS has a Pure C implementation of WebRTC that might be helpful! https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/tree/master/src/source/Ice – Sean DuBois Mar 23 '20 at 19:43