[jitsi-dev] MS Edge and ice4j


#1

If anyone else on the list has any idea whats going wrong here when I try
to use Edge and ice4j; I'd be happy with the input. The error I see is:

ConnectivityCheckServer - Failed to send BINDING-RESPONSE(0x101)

I have a full gist with my offer->answer->etc.. for further details (i
changed my public IP in the gist, so any xor stuff done by hand might fail)
https://gist.github.com/mondain/983892136d64975c9871c6ecedda7a29

Regards,
Paul


#2

You may be running into en Edge bug, make sure you are running the latest ice4j version and toggle this option on: https://github.com/jitsi/ice4j/pull/119/files

Cheers,

-Saúl

···

On Jul 8, 2017, at 04:49, Mondain <mondain@gmail.com> wrote:

If anyone else on the list has any idea whats going wrong here when I try to use Edge and ice4j; I'd be happy with the input. The error I see is:

ConnectivityCheckServer - Failed to send BINDING-RESPONSE(0x101)

I have a full gist with my offer->answer->etc.. for further details (i changed my public IP in the gist, so any xor stuff done by hand might fail)
https://gist.github.com/mondain/983892136d64975c9871c6ecedda7a29

Regards,
Paul

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hi Paul,

From what we've observed, Edge some of the Binding Requests (BR) send from Edge have two copies: one with the correct USERNAME, and one with the "length" field of the USERNAME messed up.

The way we worked around this is by stripping the zero bytes from the USERNAME, and this makes the two packets look identical to ice4j. In the case of incoming BR this seems work (e.g. the extra BR doesn't cause any problems).

It looks like the errors in your logs are related to this, and I don't think they are fatal: ice4j received one BR, sent a response, then received the second copy of the same BR and it complains that it has already sent a response. So, while I don't know what is causing the problem, I think these logs might be a red hairing -- consider also looking for other causes.

Regards,
Boris

···

On 07/07/2017 21:49, Mondain wrote:

If anyone else on the list has any idea whats going wrong here when I try to use Edge and ice4j; I'd be happy with the input. The error I see is:

ConnectivityCheckServer - Failed to send BINDING-RESPONSE(0x101)

I have a full gist with my offer->answer->etc.. for further details (i changed my public IP in the gist, so any xor stuff done by hand might fail)
https://gist.github.com/mondain/983892136d64975c9871c6ecedda7a29

Regards,
Paul

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hello Saul,
Thanks for the reply. We already enforce removal of the trailing zeros in
our builds and still have the binding error with Edge. I did more research
and found a promising bug here
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7718294/
but
MS marked it as wont-fix :frowning:
I'll spend some time in ice4j source and see if I can work around it, since
its an Edge support blocker for us.

Regards,
Paul

···

On Sat, Jul 8, 2017 at 3:40 AM Saúl Ibarra Corretgé <scorretge@atlassian.com> wrote:

You may be running into en Edge bug, make sure you are running the latest
ice4j version and toggle this option on:
https://github.com/jitsi/ice4j/pull/119/files

Cheers,

-Saúl

On Jul 8, 2017, at 04:49, Mondain <mondain@gmail.com> wrote:

If anyone else on the list has any idea whats going wrong here when I try
to use Edge and ice4j; I'd be happy with the input. The error I see is:

ConnectivityCheckServer - Failed to send BINDING-RESPONSE(0x101)

I have a full gist with my offer->answer->etc.. for further details (i
changed my public IP in the gist, so any xor stuff done by hand might fail)
https://gist.github.com/mondain/983892136d64975c9871c6ecedda7a29

Regards,
Paul

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Thanks for the details Boris, I believe the length / 0 stripping works for
sure and Edge is certainly sending bad lengths. I think the inclusion of
the username in stun messages where it violates the rfc might be causing
ice4j to fail pairs that should be valid; again this is Edge sending
unsupported attributes. If I figure it out I'll pass on the info.

Regards,
Paul

···

On Tue, Jul 11, 2017, 12:28 Boris Grozev <boris@jitsi.org> wrote:

Hi Paul,

From what we've observed, Edge some of the Binding Requests (BR) send
from Edge have two copies: one with the correct USERNAME, and one with
the "length" field of the USERNAME messed up.

The way we worked around this is by stripping the zero bytes from the
USERNAME, and this makes the two packets look identical to ice4j. In the
case of incoming BR this seems work (e.g. the extra BR doesn't cause any
problems).

It looks like the errors in your logs are related to this, and I don't
think they are fatal: ice4j received one BR, sent a response, then
received the second copy of the same BR and it complains that it has
already sent a response. So, while I don't know what is causing the
problem, I think these logs might be a red hairing -- consider also
looking for other causes.

Regards,
Boris

On 07/07/2017 21:49, Mondain wrote:
> If anyone else on the list has any idea whats going wrong here when I
> try to use Edge and ice4j; I'd be happy with the input. The error I see
is:
>
> ConnectivityCheckServer - Failed to send BINDING-RESPONSE(0x101)
>
> I have a full gist with my offer->answer->etc.. for further details (i
> changed my public IP in the gist, so any xor stuff done by hand might
fail)
> https://gist.github.com/mondain/983892136d64975c9871c6ecedda7a29
>
> Regards,
> Paul
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>


#6

I'm still collecting evidence for this issue, but right now it looks like
an Edge bug where they are sending the wrong length in some of the STUN
messages. When I file a report I'll post the link here for those interested.

Paul

···

On Sat, Jul 8, 2017 at 7:09 AM Mondain <mondain@gmail.com> wrote:

Hello Saul,
Thanks for the reply. We already enforce removal of the trailing zeros in
our builds and still have the binding error with Edge. I did more research
and found a promising bug here
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7718294/ but
MS marked it as wont-fix :frowning:
I'll spend some time in ice4j source and see if I can work around it,
since its an Edge support blocker for us.

Regards,
Paul

On Sat, Jul 8, 2017 at 3:40 AM Saúl Ibarra Corretgé < > scorretge@atlassian.com> wrote:

You may be running into en Edge bug, make sure you are running the latest
ice4j version and toggle this option on:
https://github.com/jitsi/ice4j/pull/119/files

Cheers,

-Saúl

On Jul 8, 2017, at 04:49, Mondain <mondain@gmail.com> wrote:

If anyone else on the list has any idea whats going wrong here when I try
to use Edge and ice4j; I'd be happy with the input. The error I see is:

ConnectivityCheckServer - Failed to send BINDING-RESPONSE(0x101)

I have a full gist with my offer->answer->etc.. for further details (i
changed my public IP in the gist, so any xor stuff done by hand might fail)
https://gist.github.com/mondain/983892136d64975c9871c6ecedda7a29

Regards,
Paul

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

I've found a new clue in the Edge madness; The message integrity check
fails, whereas it passes with any other webrtc browser. I hope to code a
work around in the next 24 hours, but we shall see. Heres a portion of my
log for reference:

Message Processor] TRACE org.ice4j.stack.StunStack - Received a message on
10.0.0.5:49152/udp of type:1
2017-07-12 16:41:33,719 [Stun4J Message Processor] TRACE
org.ice4j.stack.StunStack - parsing request
2017-07-12 16:41:33,719 [Stun4J Message Processor] TRACE
org.ice4j.stack.StunStack - existing transaction not found
2017-07-12 16:41:33,719 [Stun4J Message Processor] TRACE
org.ice4j.stack.StunStack - Received a message on 10.0.0.5:49152/udp of
type:1
2017-07-12 16:41:33,720 [Stun4J Message Processor] TRACE
org.ice4j.stack.StunStack - parsing request
2017-07-12 16:41:33,721 [Stun4J Message Processor] TRACE
org.ice4j.stack.StunStack - found an existing transaction
2017-07-12 16:41:33,721 [Stun4J Message Processor] TRACE
org.ice4j.stack.StunStack - Response retransmitted
2017-07-12 16:41:33,722 [Stun4J Message Processor] DEBUG
org.ice4j.stack.StunStack - Received a message with a wrong
MESSAGE-INTEGRITY HMAC-SHA1 signature: expected:
367AB7BCA426DE6F1EFBBE875880DF3013093EF7, received:
DF97B2AC8E8E22D34ED28749C479C2222C367D8C
2017-07-12 16:41:33,724 [Stun4J Message Processor] WARN
org.ice4j.stack.StunStack - Failed to validate msg: StunMessageEvent:
Message=BINDING-REQUEST(0x1)[attrib.count=7 len=92
tranID=0x23A1F30B4DD779428DAA86CC] remoteAddr=10.0.0.12:53282/udp localAddr=
10.0.0.5:49152/udp
java.lang.IllegalArgumentException: Wrong MESSAGE-INTEGRITY value.
at org.ice4j.stack.StunStack.validateRequestAttributes(StunStack.java:1197)
at org.ice4j.stack.StunStack.handleMessageEvent(StunStack.java:974)
at org.ice4j.stack.MessageProcessor.run(MessageProcessor.java:171)
at java.lang.Thread.run(Thread.java:748)

···

On Tue, Jul 11, 2017 at 1:12 PM Mondain <mondain@gmail.com> wrote:

Thanks for the details Boris, I believe the length / 0 stripping works for
sure and Edge is certainly sending bad lengths. I think the inclusion of
the username in stun messages where it violates the rfc might be causing
ice4j to fail pairs that should be valid; again this is Edge sending
unsupported attributes. If I figure it out I'll pass on the info.

Regards,
Paul

On Tue, Jul 11, 2017, 12:28 Boris Grozev <boris@jitsi.org> wrote:

Hi Paul,

From what we've observed, Edge some of the Binding Requests (BR) send
from Edge have two copies: one with the correct USERNAME, and one with
the "length" field of the USERNAME messed up.

The way we worked around this is by stripping the zero bytes from the
USERNAME, and this makes the two packets look identical to ice4j. In the
case of incoming BR this seems work (e.g. the extra BR doesn't cause any
problems).

It looks like the errors in your logs are related to this, and I don't
think they are fatal: ice4j received one BR, sent a response, then
received the second copy of the same BR and it complains that it has
already sent a response. So, while I don't know what is causing the
problem, I think these logs might be a red hairing -- consider also
looking for other causes.

Regards,
Boris

On 07/07/2017 21:49, Mondain wrote:
> If anyone else on the list has any idea whats going wrong here when I
> try to use Edge and ice4j; I'd be happy with the input. The error I see
is:
>
> ConnectivityCheckServer - Failed to send BINDING-RESPONSE(0x101)
>
> I have a full gist with my offer->answer->etc.. for further details (i
> changed my public IP in the gist, so any xor stuff done by hand might
fail)
> https://gist.github.com/mondain/983892136d64975c9871c6ecedda7a29
>
> Regards,
> Paul
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>


#8

Any news or update on this topic? We are running into the same issue when using webrtc to Red5 which uses ice4j.


#9

We’re also struggling with this. Edge is a smaller percent of our users, but still big enough that we can’t move forward with a WebRTC/non-Flash solution that doesn’t include Edge. Any updates would be greatly appreciated!


#10

Can you elaborate on what you’re seeing with edge? The issue related to underlying ICE binding problems with edge was fixed a while ago here.


#11

In the jitsi ice4j library there is a workaround (if its still there) for Edge; However, Edge still continues to improperly re-use the same transaction id on different requests causing issues with at least our particular fork. I submitted an issue report with MS quite some time ago, but they don’t appear interested in fixing their bug. Microsoft has since removed the actual content of my issue report, even though it appears in the search:

Edge ICE improper Transaction Id usage

Edge’s ICE Agent is using transaction id’s incorrectly. The same transaction id is being used for duplicate requests which consist of different content. As shown below from the server log, the same id…

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/14544363/

The message integrity issue is according to them “by design”: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7728584/


#12

Perhaps this the the 3489 vs 5389 issue, or a similar one? What if we
just drop all 3489 packets?

Boris


#13

I’m not sure I’m following which workaround you’re referring to Mondain–do you mean the fix to properly ignore 3489-style packets? Edge shouldn’t send any 3489 packets after the initial one since we never respond on it, so after the initial message ICE4j should be ok. Or maybe I’m misunderstanding what you’re saying here?


#14

The username padding fix in the jitsi build is what I was referring to.


#15

Gotcha…are you able to upgrade the ICE4j version and use the newer fix?


#16

Personally I’ll have to circle back to see where you guys are at with the original ice4j and any Edge handling; our fork is more specialized for our server and relies on Mina for networking. Edge is really low priority in our world, especially given the non-support of MS for WebRTC at this time. :frowning: