Summary:ASTERISK-20702: res_rtp_asterisk.c:3455 ast_rtp_read: RTP Read error: Invalid or incomplete multibyte or wide character. Hanging up.
Reporter:David Brillert (aragon)Labels:
Date Opened:2012-11-19 09:36:06.000-0600Date Closed:2012-12-18 08:21:48.000-0600
Versions:11.0.1 Frequency of
is related toASTERISK-20288 PhonerLite reports RTP read error when ICE Support Enabled
Environment:Asterisk 11.0.1 Snom 8.x firmwareAttachments:( 0) messages
( 1) sip.pcap
Description:All calls to Snom phones hangup when answer with WARNING res_rtp_asterisk.c:3455 ast_rtp_read: RTP Read error: Invalid or incomplete multibyte or wide character.  Hanging up.

Snom config user_ice1!: off
icesupport = yes

verbose log with sip debug attached.
234( calls Snom 223(
Comments:By: David Brillert (aragon) 2012-11-19 09:37:50.242-0600

I also have a SIP tcpdump if required.

By: Joshua C. Colp (jcolp) 2012-11-19 09:43:58.646-0600

The tcpdump would be useful here but what it looks like is that the Snom is sending an improper STUN packet to Asterisk, which pjnath is rejecting and then returning an error.

By: David Brillert (aragon) 2012-11-19 09:50:44.289-0600

Here is the tcpdump.
I should add that I can only reproduce this with Snom phones.
XLite with ICE is not affected.

By: Joshua C. Colp (jcolp) 2012-11-19 09:53:30.293-0600

The pcap can't be opened, Wireshark claims it is corrupted.

By: David Brillert (aragon) 2012-11-19 09:56:16.895-0600

RTP works OK if I set
icesupport = no

By: David Brillert (aragon) 2012-11-19 09:59:34.536-0600

Sorry, I tried to scrub the tcpdump and that must have corrupted it.  The pcap is some from a production system that I didn't want to make too public...
It should open in notepad or a text editor.

By: Joshua C. Colp (jcolp) 2012-11-19 10:01:32.940-0600

I actually wanted to see the STUN packet to see what the Snom is sending. It strongly looks like this is a Snom issue, though. I'd suggest just setting icesupport to no for that device.

By: David Brillert (aragon) 2012-11-19 10:27:45.260-0600

There appears to be an interop problem with Snom.
icesupport=yes in sip.conf will not work with the Snom default user_ice1!: off but does work if Snom provisioning =
user_ice1!: on

By: Matt Jordan (mjordan) 2012-11-20 06:51:13.335-0600

I guess I'm missing how this is an Asterisk problem.  You've configured Asterisk with ICE support, but disabled it in the Snom.  From the [Snom settings description of user_ice|http://wiki.snom.com/Settings/user_ice]:

Choose whether or not you want to use ICE (Interactive Connectivity Establishment). ICE optimizes the media path. This would be the case, for example, when two phones in the same network are calling each other via a long media path through other, external networks. With ICE, the short media path in the same network would be chosen, which will presumably have better quality than the long one. Sometimes this feature will stop you from being able to make calls. When this occurs, switch it off.

Configuring a setting in Asterisk that the physical device isn't configured to support is always going to be a bad idea.

By: David Brillert (aragon) 2012-11-20 08:54:52.913-0600

To the contrary since I have already stated "There appears to be an interop problem with Snom."

It is the default settings for each that are responsible for the conflict and create problems:
1. The default setting for icesupport in Asterisk 11 is yes.  https://wiki.asterisk.org/wiki/display/~jcolp/ICE,+STUN,+and+TURN+Support
2. The default setting for icesupport in Snom is no.  http://wiki.snom.com/Settings/user_ice

I've already worked around the conflict with /etc/asterisk/rtp.conf/icesupport=no
And with /etc/asterisk/rtp.conf/icesupport=yes I tested XLite>ICE disabled and enabled without any issues.

I'm leery of enabling ICE in the Snom with the optional setting 'user_ice1!: on' as a workaround since Snom clearly states the following on their wiki:
"Note, that ICE currently will work reliable in OCS environment only".

Matt, feel free to close this out if you want since a workaround exists.
At least this problem is well documented for others who run into the same problem.

By: Matt Jordan (mjordan) 2012-11-20 09:30:43.452-0600

Josh's page in his personal space isn't documentation for ICE - when we released Asterisk 11, we disabled ICE support by default.  The [official|https://wiki.asterisk.org/wiki/display/AST/New+in+11] [wiki pages|https://wiki.asterisk.org/wiki/display/AST/Interactive+Connectivity+Establishment+%28ICE%29+in+Asterisk] do need to be updated however (oops) - that should be corrected.  {{rtp.conf.sample}} does note correctly that icesupport is disabled by default.

If, however, you pulled .conf files over from the beta, then it would be enabled by default.

So the default settings in Snom and Asterisk don't conflict.  Mixing settings between a device and Asterisk I suppose could be called an 'interop problem', but it feels more like a bad configuration then anything else.  The fact that Snom doesn't trust their handling of ICE doesn't change that fact.

I do agree that there is something different between what the Snom sends when its configured to send STUN packets outside of ICE support and what XLite is doing.  As Josh mentioned, it would be nice to get a pcap of the Snom traffic to see what about their STUN candidates is annoying Asterisk.

By: David Brillert (aragon) 2012-11-20 10:13:15.873-0600

Thanks for the official link.
I stand corrected on the default behavior of Asterisk 11.
Sorry about the corrupt pcap but I didn't want to expose my IP addresses etc.
Would you be so kind as to delete the sip.pcap I already uploaded?

Based on my current work load I won't be able to build a test system to reproduce the Snom pcaps for several weeks (and I don't have any unused Snom phones lying around).
But this is really easy to reproduce with /etc/asterisk/rtp.conf/icesupport=yes and default ice settings on the Snom phone.  Just call the Snom from a Polycom phone and try to answer the Polycom.

By: David Brillert (aragon) 2012-11-20 13:06:47.216-0600

Matt, I see you edited some documentation today at https://wiki.asterisk.org/wiki/display/AST/Interactive+Connectivity+Establishment+(ICE)+in+Asterisk

I still find this documentation confusing...
"Since ICE is enabled by default, configuration of the STUN server and optionally, the TURN server, is all that is required to get things running."

By: Matt Jordan (mjordan) 2012-11-20 14:53:53.116-0600

Missed that.  Fixed :-)

By: David Brillert (aragon) 2012-11-20 15:03:27.879-0600

Now I can't remember where I found this comment but it was somewhere on the official wiki.
I found the comment sensible.

Joshua Colp
The next release of Asterisk 11 will have ICE support enabled by default in res_rtp_asterisk, but disabled by default in chan_sip

I assume this to mean that best practice should do the following:
edit icesupport=yes per peer as needed
and provision the client as needed

By: Joshua C. Colp (jcolp) 2012-11-26 13:16:03.658-0600

You won't have to explicitly set icesupport=yes in rtp.conf or icesupport=no in the sip.conf general section, that will be the default going forward. As you did mention though you must set icesupport=yes peer and set it on the client.

By: Rusty Newton (rnewton) 2012-11-26 13:30:26.402-0600

Putting this in 'waiting on feedback' until David is able to get the snom pcaps

By: David Brillert (aragon) 2012-11-29 08:17:58.820-0600

I reproduced and captured verbose Asterisk log with sip set debug on and grabbed a tcpdump on a new development server.
Using the following settings results in a disconnect when Snom phone calls another extension and the extension answers.
Do not enable the ice settings in the Snom (default ice settings)

I realize these are not the default settings in Asterisk 11 but those are the steps to reproduce.  Agreed this is a problem with Snom phone.

By: Rusty Newton (rnewton) 2012-12-18 08:21:49.016-0600

Closing this out since we believe this is an issue with the SNOM phone and not a bug with Asterisk.

If something changes you can always contact a bug marshal in #asterisk-bugs or via the asterisk-dev mailing list.