No ice

[lisay-yan]

Description

Reference issue

Fixes #...

[Sean-Der]

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 NoICE option. If we merge this it will break WASM/interop with other implementations.

What are you trying to achieve?

• Do you want to remove signaling requirements?
• Are you trying to reduce implementation complexity?
• Are you trying to reduce connection times?

[lisay-yan]

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 NoICE option. If we merge this it will break WASM/interop with other implementations.

[Lisa] ICE is designed for NAT traversal.
https://datatracker.ietf.org/doc/html/rfc8445
Agree that is common need for WASM. That is why introduce ICENone configuration in peerconn, which default is false to guard not impact WASM/interop.

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.

What are you trying to achieve?
[Lisa] Try to provide common webrtc based solution for no NAT scenarios.

• Do you want to remove signaling requirements?
  [Lisa] No NAT, No ICE, stun steps should be skipped.
• Are you trying to reduce implementation complexity?
  [Lisa] Only turn on ICENone for no NAT deployment.
• Are you trying to reduce connection times?
  [Lisa] Yes, it is indeed faster than perform ICE full steps. And that is indeed not necessary for no NAT deployment.

[stv0g]

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.

[lisay-yan]

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.

@stv0g

First of all, pion will fall back to ICE full if two sides are ice lite.
And for IMS usage:
Access network only deliver c line and port in m line to indicate media path since no NAT in IMS core network.
Pion is used in IMS core network to provide IMSDC service described at 3gpp 26114.
So, ICE lite is useless for IMS core side components.

@Sean-Der @stv0g
Would you like give more wise proposal for only c line and port in m line based SDP negotiation via pion/webrtc?
Agree my idea is draft and try best to reuse all state in webrtc now.

Appreciate your support in advance.

Lisa

[hankliu9]

Hi @Sean-Der @stv0g

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.
Pion no ICE.docx

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,
Hank

[stv0g]

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).

[Sean-Der]

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 NoICE mode isn't something I can do (just not part of the standard). I can give you hooks to do whatever you wish though :)

[hankliu9]

Hi @Sean-Der @stv0g

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,
Hank