Compatibility issues with Asterisk Telephony Server (DTLS Server_Hello not accepted)

RESOLVED INVALID

Status

()

Core
WebRTC
RESOLVED INVALID
4 years ago
4 years ago

People

(Reporter: marko.seidenglanz, Unassigned)

Tracking

35 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 8503954 [details]
dump_ast_ff_35_2014_10_09.pcap

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.13 Safari/537.36

Steps to reproduce:

1. Connetion setup with Asterisk Telephony Server using testing URL (DIAL):
http://test.webrtc.24dial.com/web/index.html

2.1 SDP exchange
2.2 DTLS Handshake starts
2.2.1 Client Hello from FF
2.2.2 Server Hello from Asterisk


Actual results:

FF does not respond with "Client Key Exchange", "Change Cipher Spec" and subsequent Handshake Message


Expected results:

FF should respond with "Client Key Exchange", "Change Cipher Spec" and subsequent Handshake Message. (Was working in FF <= 34)
If you look at packet number 82 in the attached trace you will see that the Server Hello from Asterisk to FF gets send to port number 9. This is not where the Client Hello came from, and this is also not what the ICE success responses were send to. Asterisk needs to send the Server Hello back to port 34465.
Closing as this seem to be an Asterisk bug to me.
Feel free to re-open if you disagree.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

4 years ago
(In reply to Nils Ohlmeier [:drno] from comment #1)
> If you look at packet number 82 in the attached trace you will see that the
> Server Hello from Asterisk to FF gets send to port number 9. This is not
> where the Client Hello came from, and this is also not what the ICE success
> responses were send to. Asterisk needs to send the Server Hello back to port
> 34465.

That is right, packet number 81 goes to the wrong port, but all subsequent Hellos go to 34465 and are not answered as well. Port 9 is adressed, because the SDP generated by FF 35 says port 9 as media port in the media description. Please have a look at packet 65.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Please dump the SDP's received by JS (for SetRemoteDescription) and generated by CreateOffer or CreateAnswer, not the SDP after transforming it into a SIP message.
(Reporter)

Comment 5

4 years ago
You can now see the SDP created by the browser indicated by the prefix "ANSWER SDP: ".
(In reply to marko.seidenglanz from comment #3)
> (In reply to Nils Ohlmeier [:drno] from comment #1)
> > If you look at packet number 82 in the attached trace you will see that the
> > Server Hello from Asterisk to FF gets send to port number 9. This is not
> > where the Client Hello came from, and this is also not what the ICE success
> > responses were send to. Asterisk needs to send the Server Hello back to port
> > 34465.
> 
> That is right, packet number 81 goes to the wrong port, but all subsequent
> Hellos go to 34465 and are not answered as well. Port 9 is adressed, because
> the SDP generated by FF 35 says port 9 as media port in the media
> description.

Yes, and port 9 is advertised because of trickle ICE. We should probably at some point change it so that if the JS code waits for the full SDP including the ICE candidates that the m line gets updated with at least a host IP and port number.

> Please have a look at packet 65.

So looking at all the subsequent Hello exchanges I noticed that the Asterisk server Hello is pretty big, well over 1500 bytes. Therefore the packet gets fragmented. Now the question is if the NAT in front of your Firefox lets fragmented UDP back in. Can you please make a wireshark trace on the Firefox client machine as well?

For me it works just fine with 34 from our office and my home network. I just checked that my home network properly routes the fragmented Server Hello to my FF. But lots of NATs won't handle this properly.

BTW it looks like you are running your Asterisk on a private IP address, but you only offer Google STUN server, but no TURN server. This is not going to work very well for real deployments.
Flags: needinfo?(marko.seidenglanz)
(Reporter)

Comment 7

4 years ago
Created attachment 8505297 [details]
dump_ast_ff_35_2014_09_15_serverside.pcap
Flags: needinfo?(marko.seidenglanz)
(Reporter)

Comment 8

4 years ago
Created attachment 8505298 [details]
dump_ast_ff_35_2014_09_15_clientside
(Reporter)

Comment 9

4 years ago
I've uploaded a simultaneous trace on clientside and serverside. I forgot the file extension in the second upload, but it should also work with Wireshark.

The first Server Hello to port 9 seems to be discarded on FF side, but all subsequent Server Hello messages arrive. Wireshark tells me, that on the serverside trace the DTLS Server Hello can not be reassembled, but on clientside they are displayed.... hmmm. I will start a second try.

Until now we did not need a turn server as it works with our setup, but thank you for the advise. It also works with FF 34. The problem only appears with FF 35.
(Reporter)

Comment 10

4 years ago
Ok... There is always a Ureassembled Packet Warning (Client and Serverside), but that is ok I think, because the message is encrypted or?

I cannot see the cause, why it should not be accepted by FF 35.
Thanks for providing the traces from both sides.

It appears that Wireshark claims to always re-assemble the first Server Hello (the one to port 9 on the server side and on the client side the first retransmitted Hello with DTLS seq 5 in it). But then it fails to re-assemble all further Server Hellos.

We were not able to identify any problems with the packets from the traces. As it works fine for me with 35 from two different networks, my best guess at this time is that it is related to your local setup.

Two ideas for further debugging:
- Have you tried this with a fresh Firefox user profile yet? Not sure how a profile could influence this, but might be worth a try.
- We noticed that the Server Hello from Asterisk is awfully big as it seems to send a full certificate. But for DTLS to work a super simple cert just with a public key in it would be enough. That way you could potentially get the Server Hello packet below the MTU size and avoid fragmentation.
(Reporter)

Comment 12

4 years ago
I recently tested on a Windows PC in the same network and it worked, though it took about 3 seconds until the ICE state changed to 'connected'. On my linux PC it's still not working, though I've created a new profile. I will investigate this. 

Thank you for your help!
(Reporter)

Comment 13

4 years ago
To my surprise, creating a new profile did the job. It works in 35 and 36 too.

Thank you very much for your help!
Surprising that a profile can have such an influence, but glad we could finally solve it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.