[jitsi-dev] [ice4j] Firefox STUN implementation on WebRTC


#1

Hello,

I am working on a WebRTC client that uses ice4j to process STUN/TURN
messages, which are in the WebRTC standard. In the Firefox implementation
of STUN stack, they reply to a Binding Request User a 401 (Unauthorized)
packet at the beginning of the communication, but after repeating some
times the Binding Request User the answer becomes the expected Binding
Success Response (with an XOR-MAPPED-ADDRESS).

On ice4j, when receiving a non successful response to a Binding Request
User the whole candidate pair is removed from the possible list.

I don't really know if the Firefox behaviour is contemplated in the STUN
standard, but I've done a modification in my ice4j to adapt the STUN stack
to this situation. The idea is that if a 401 response is received, I resend
a Binding Request User after 100 milliseconds. If I receive a 401 10 times
or more it is when I finally reject the candidate pair.

I enclose a possible implementation of the method processErrorResponse in
the ConnectivityCheckClient class and the Wireshark capture of the STUN
packets that have been sent in my implementation.

Thank you,
Jairo

processErrorResponse.java (3.37 KB)

stun401ice4j.pcap (5.75 KB)


#2

Hey Jairo,

Hello,

I am working on a WebRTC client that uses ice4j to process STUN/TURN
messages, which are in the WebRTC standard. In
the Firefox implementation of STUN stack, they reply to a Binding
Request User a 401 (Unauthorized) packet at the beginning of the
communication, but after repeating some times the Binding Request User
the answer becomes the expected Binding Success Response (with an
XOR-MAPPED-ADDRESS).

Sounds weird.

On ice4j, when receiving a non successful response to a Binding Request
User the whole candidate pair is removed from the possible list.

Here's what RFC 5245 says about this:

    If the STUN transaction generates a
    STUN error response that is unrecoverable (as defined in [RFC5389])
    or times out, the agent sets the state of the pair to Failed.

I don't really know if the Firefox behaviour is contemplated in the STUN
standard,

No, if I am properly understanding your description, this sounds like a problem with Firefox and you might want to report it to them. Their WebRTC implementation is currently a work in progress and I would expect them to be open to issue reports.

but I've done a modification in my ice4j to adapt the STUN
stack to this situation. The idea is that if a 401 response is received,
I resend a Binding Request User after 100 milliseconds. If I receive a
401 10 times or more it is when I finally reject the candidate pair.

I enclose a possible implementation of the method processErrorResponse
in the ConnectivityCheckClient class and the Wireshark capture of the
STUN packets that have been sent in my implementation.

Thank you for sending this, however, as you must have noticed already, the ICE implementation is already complex enough as it is. I'd really rather we didn't complicated further with code that works around someone else's bugs :).

Again, I see no reason why Firefox wouldn't want to fix the issue.

Cheers,
Emil

···

On 30.08.13, 14:37, Jairo Canales Alfonso wrote:

--
https://jitsi.org


#3

I have reported the issue in a WebRTC for Firefox group:
https://groups.google.com/forum/#!topic/mozilla.dev.media/K2D47BQ7IxY .

Thank you very much Emil for your answer :slight_smile:

···

2013/8/30 Emil Ivov <emcho@jitsi.org>

Hey Jairo,

On 30.08.13, 14:37, Jairo Canales Alfonso wrote:

Hello,

I am working on a WebRTC client that uses ice4j to process STUN/TURN
messages, which are in the WebRTC standard. In
the Firefox implementation of STUN stack, they reply to a Binding
Request User a 401 (Unauthorized) packet at the beginning of the
communication, but after repeating some times the Binding Request User
the answer becomes the expected Binding Success Response (with an
XOR-MAPPED-ADDRESS).

Sounds weird.

On ice4j, when receiving a non successful response to a Binding Request

User the whole candidate pair is removed from the possible list.

Here's what RFC 5245 says about this:

   If the STUN transaction generates a
   STUN error response that is unrecoverable (as defined in [RFC5389])
   or times out, the agent sets the state of the pair to Failed.

I don't really know if the Firefox behaviour is contemplated in the STUN

standard,

No, if I am properly understanding your description, this sounds like a
problem with Firefox and you might want to report it to them. Their WebRTC
implementation is currently a work in progress and I would expect them to
be open to issue reports.

but I've done a modification in my ice4j to adapt the STUN

stack to this situation. The idea is that if a 401 response is received,
I resend a Binding Request User after 100 milliseconds. If I receive a
401 10 times or more it is when I finally reject the candidate pair.

I enclose a possible implementation of the method processErrorResponse
in the ConnectivityCheckClient class and the Wireshark capture of the
STUN packets that have been sent in my implementation.

Thank you for sending this, however, as you must have noticed already, the
ICE implementation is already complex enough as it is. I'd really rather we
didn't complicated further with code that works around someone else's bugs
:).

Again, I see no reason why Firefox wouldn't want to fix the issue.

Cheers,
Emil

--
https://jitsi.org