-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No ice #2539
No ice #2539
Conversation
Hi @lisay-yan I am really sorry, but I think we need to make some changes before this is merged. WebRTC doesn't have a What are you trying to achieve?
|
[Lisa] ICE is designed for NAT traversal. IMSDC (3gpp 26.114) is based on webrtc. In typical IMS deployments, it is expected that no need to use NAT at core network. So, ICE is not necessary for no NAT network. That is the key trigger to implement ICENone.
|
I am agreeing with @Sean-Der here, that this is not covered by any RFC and we should be careful to include it. @lisay-yan I also have some difficulties to understand your use case. What you describe sounds like you want to have a lite ICE agent? See: https://www.rfc-editor.org/rfc/rfc8445#section-2.5 And lite agents are already supported by Pion. |
First of all, pion will fall back to ICE full if two sides are ice lite. @Sean-Der @stv0g Appreciate your support in advance. Lisa |
This is Hank from Nokia. I'm in same group as @lisay-yan. First of all, thanks you all for providing the great Pion WebRTC stack. The Pion helps us quickly building up IMS data channel solution! I want to give you more backgroud on how we use the Pion in IMS network as attachment. In short, no-ICE use case is common in IMS Core network since there is NO NAT in IMS deployment. In addtion to ICE case, supporting no-ICE could make Pion more attractive and popular in telecom. If you agree, we can contribute our change on Pion to support no-ICE use case based on configuration/input w/o impact on existing use cases. Welcome comments/suggestions. Kind regards, |
Hi @hankliu9, Please have a look at the design proposal in pion/ice#623 by @Sean-Der to address your use case. Please note that we are primarily targeting the IETF RFCs and W3C specification with the Pion implementation. However, we still would like to enable your use case by using custom implementations of the interfaces as discussed in the issue linked above. I am wondering, why dont you simply limit Pion to use host candidates only? It should still work that way. Thats what ICE was designed for. You have not answered @Sean-Der questions in #2539 (comment). |
Very cool! Thanks for sharing @lisay-yan @hankliu9 You don't want ICE at all because your communicating with a a non-webrtc endpoint. We totally can make this work. I will work on a PR this weekend to support what you are building. Having a |
Thanks for your comments and suggestions! Yes, it's mobile device for IMS Data Channel client, which is not WebRTC client. In IMS Core network, the IMS Data Channel connection is also in between IMS AGW and DCMF, which is network-to-network interface and no NAT. If the DC Media Function (we're using Pion to build up) supports ICE lite (host candidates only), the IMS AGW (counterpart) is also required to support ICE or ICE lite. Currently, the IMS AGW does NOT support ICE in core side at all. Then still have interworking issue between ICE lite agent and no-ICE agent. For both ICE lite agents case, from my understanding, the RFC8445 doesn't have very details on how it works since ICE lite agent doesn't generate connectivity check and nominating candidates request, just in passive mode. Thanks for working on pion/ice#623, which shall make NoICE mode implementation much easy. Then we can make NoICE implementation based on it. Once we implementate the NoICE mode, can we contribute it into Pion? Again, it shall be prefect if you can implementate the NoICE mode in Pion since you're master on Pion. Then the Pion can support both WebRTC and IMS Data Channal cases, which shall increase Pion in leading position in WebRTC stack. Lisa and I are on holiday for incoming whole week. Looking forward to checking your comments and new implementation once come back. Cheers, |
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Allow the user to perform custom processing for inbound STUN Binding requests. This allows users to do some of the following * Log incoming Binding Requests for debugging * Implement draft-thatcher-ice-renomination * Implement custom CandidatePair switching logic Resolves pion/webrtc#2539 Resolves pion/webrtc#2585 Resolves #623
Description
Reference issue
Fixes #...