AAstra 9143i STUN client broken?

I spent some more time investigating this. First, I updated the firmware to the latest 2.5.2.1010. The phone had trouble starting up after that, I had to do a factory reset and re-provision it (fortunately we have an FTP server set up for that).

Second, it seems I was using a bad STUN server, so I changed from stunserver.org to stun01.sipphone.com.

After that the SIP messages still had private IP addresses in them. However I was able to make the phone work by setting nat=yes on the Trixbox machine, but I was looking for a solution that didn't need this setting.

What I have found is that the phone can discover its external address/port with STUN, but only when it sets up the RTP stream to make a call! Of course if the SIP messages aren't properly mapped with the external address/port then the phone can never register and never make calls in the first place.

Setting nat=yes on the server allows the SIP conversation to work (telling Asterisk to ignore the IP address given by the phone). When the first call is made, the phone's STUN client springs to life and finds the correct external address. You can see that its working by log line that says:

InternalRegisterA: (SIP) INFO: localCurrentUrl: DisplayName: John Smith Host: 1.2.3.4
(where 1.2.3.4 is the external public IP address).

Followed by lots of:
_SendOneByteKeepAlivePacket: (STUN) INFO: Client 80dca9b8 sent keep-alive packet to 69.0.208.27:3478

Once it obtains an external IP address it almost works. In fact I tried settingh nat=no on the server at this point to see if it would register correctly. Subsequent register packets have the external IP in the Contact field, but they still have the private IP in the Via field. Asterisk is trying to send replies to that private address.

So, if any Aastra developers are reading this, it'd be worth testing your firmware on a network behind a NAT router with the server outside the local network. It's probably a good idea to make sure UPnP isn't enabled either.

(I'm happy to supply Wireshark traces and test firmware for you if it helps)

Hi All,

Just a quick update on this situation. I've been in contact with Aastra support and at their request made some Wireshark dumps showing the errors in the SIP conversation. I have a very cheap VanAccess phone which does the right thing with STUN so I sent them a trace of that phone as well for comparison.

I haven't heard back from their developers yet, but hopefully we'll see a STUN fix in a future firmware version.

Darrin

Well its taken a while, but I've spent some time with Aastra support looking into this.

It turns out that the STUN support in the Aastra phones is not used for SIP messaging. It's only used for the RTP stream setup. This is a design decision by Aastra.

Aastra recommend using "rport" (RFC 3581) for handsets behind a NAT firewall. When this is enabled, the handset tells the serve that its behind NAT, and the server sends SIP replies back to the UDP source address rather than the address in the Via header.

The problem is, it seems to me that rport support is broken in Asterisk 1.6 (Trixbox 2.8.0.1). My debug suggests the server is seeing the rport flag and compensating accordingly, but is still trying to use the Via addr/port for sending replies.

In the release notes for Asterisk 1.8, there is a suggestion that this function has been reworked, so hopefully a future trixbox will have this fix:

 * The 'nat' option has now been been changed to have yes, no, force_rport, and
   comedia as valid values. Setting it to yes forces RFC 3581 behavior and enables
   symmetric RTP support. Setting it to no only enables RFC 3581 behavior if the
   remote side requests it and disables symmetric RTP support. Setting it to
   force_rport forces RFC 3581 behavior and disables symmetric RTP support.
   Setting it to comedia enables RFC 3581 behavior if the remote side requests it
   and enables symmetric RTP support.

In the meantime, it seems the only way to use an Aastra phone behind NAT is to use the Asterisk "nat=yes" option for the extension which forces rport behavior and routes all RTP audio via the Asterisk server.