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

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[marko.seidenglanz]

Attachment: 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)

Comment 1

[Nils Ohlmeier [:drno]]

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.

Comment 2

[Nils Ohlmeier [:drno]]

Closing as this seem to be an Asterisk bug to me.
Feel free to re-open if you disagree.

Comment 3

[marko.seidenglanz]

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

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 5

[marko.seidenglanz]

You can now see the SDP created by the browser indicated by the prefix "ANSWER SDP: ".

Comment 6

[Nils Ohlmeier [:drno]]

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

Comment 7

[marko.seidenglanz]

Attachment: dump_ast_ff_35_2014_09_15_serverside.pcap

Comment 8

[marko.seidenglanz]

Attachment: dump_ast_ff_35_2014_09_15_clientside

Comment 9

[marko.seidenglanz]

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.

Comment 10

[marko.seidenglanz]

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.

Comment 11

[Nils Ohlmeier [:drno]]

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.

Comment 12

[marko.seidenglanz]

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!

Comment 13

[marko.seidenglanz]

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

Thank you very much for your help!

Comment 14

[Nils Ohlmeier [:drno]]

Surprising that a profile can have such an influence, but glad we could finally solve it.