Summary:ASTERISK-15089: IAX2 Codec negotiation fails since 227580
Reporter:Chris Stone (habile)Labels:
Date Opened:2009-11-06 04:19:55.000-0600Date Closed:2009-11-10 16:08:16.000-0600
Versions:Frequency of
Environment:Attachments:( 0) 16194.cap
( 1) iax2.log
Description:I get the following on inbound IAX2 calls since 227580.

[Nov  6 10:06:41] NOTICE[26182] chan_iax2.c: Rejected connect attempt from, requested/capability '0x8 (alaw)'/'0xefc0000 (h261|h263|h263p|h264|mpeg4|red|t140)' incompatible with our capability '0xfb3 (g723|gsm|g726|adpcm|lpc10|g729|speex|ilbc|g726aal2)'.
[Nov  6 10:06:44] NOTICE[26177] test_amihooks.c: AMI Event:

These capabilities do not match what I have configured.
Comments:By: Leif Madsen (lmadsen) 2009-11-06 09:01:32.000-0600

Please provide some information so we can actually debug this issue.

Start with the IAX2 debug, console output, iax.conf file (relative parts), and a description of how to reproduce this. Additionally, the topology, and the version of Asterisk being used at the other end would also be useful.

By: Chris Stone (habile) 2009-11-06 09:16:58.000-0600

I really don't know the version at the other end as it is a service provider that works fine until this revision.

I'll what I can get from the log, as for iax.conf:

codecpriority=caller  ;tried also with host

Do let me know if you need more and I'll fire up that version again.

By: Chris Stone (habile) 2009-11-06 09:22:15.000-0600

Just out of interest, and don't take this the wrong way but it would help me to understand in the future why this would be classed minor and not major?

From my perspective it is major because it means all inbound IAX calls fail - which to me is pretty major. I apologise if this is well documented, I'm off to look now but it's been a busy day :(

By: Leif Madsen (lmadsen) 2009-11-06 09:32:35.000-0600

I dropped it to minor because there was no information to go on for debugging. I can raise it back to major now that you've provided some information.

By: Chris Stone (habile) 2009-11-07 08:15:10.000-0600

Fully understand, thanks. FYI I can work with this revision by setting: bandwidth=full and codecpriority=disabled in config but I think medium is supposed to include alaw & ulaw too..

By: Russell Bryant (russell) 2009-11-07 12:25:13.000-0600

I assigned this to Tilghman since the revision noted was his codec bit expansion.

By: Tilghman Lesher (tilghman) 2009-11-08 12:10:24.000-0600

I'm going to need to see a packet dump.

By: Tilghman Lesher (tilghman) 2009-11-08 12:11:29.000-0600

This cannot be classified as a major issue, as it's in an unreleased branch.

By: Chris Stone (habile) 2009-11-08 13:20:45.000-0600

Sorry, I didn't realise there was a different severity grading system for SVN - stupid oversight. I'll try to get the packet dump as soon as I can - pretty easy to reproduce though, at least in my environment with all IAX peers.

By: Chris Stone (habile) 2009-11-08 13:33:30.000-0600

Let me know if the attached tcpdump is OK, otherwise please advise how you would prefer the capture created.

By: Bruno Enten (benten) 2009-11-09 09:16:21.000-0600

Same problem here, even weirder :
chan_iax2.c:10705 socket_process: Rejected connect attempt from, requested/capability '0x8 (alaw)'/'0x8f80000 (h263|h263p|h264|mpeg4|t140)' incompatible with our capability '0x8 (alaw)'.

alaw is incompatible with alaw ? Almost looks like iax is trying to make a video call. What with the request for h264/... ?

By: Bruno Enten (benten) 2009-11-09 09:19:05.000-0600

Packet dump, between asterisk 1.2.10 and asterisk SVN-trunk-r228693

Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW    
  Timestamp: 00011ms  SCall: 00001  DCall: 00000 [xx.xx.xx.xx:4569]
  VERSION         : 2
  CALLED NUMBER   : 9100
  CODEC_PREFS     : (alaw)
  LANGUAGE        : en
  USERNAME        : enten-itc-cils
  FORMAT          : 8
  CAPABILITY      : 63496
  ADSICPE         : 0
  DATE TIME       : 2009-11-09  16:11:02

Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 001 Type: IAX     Subclass: AUTHREQ
  Timestamp: 00019ms  SCall: 05018  DCall: 00001 [xx.xx.xx.xx:4569]
  CHALLENGE       : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  USERNAME        : enten-itc-cils

Rx-Frame Retry[ No] -- OSeqno: 001 ISeqno: 001 Type: IAX     Subclass: AUTHREP
  Timestamp: 00055ms  SCall: 00001  DCall: 05018 [xx.xx.xx.xx:4569]
  MD5 RESULT      : xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[Nov  9 17:22:26] NOTICE[486]: chan_iax2.c:10705 socket_process: Rejected connect attempt from, requested/capability '0x8 (alaw)'/'0x8f80000 (h263|h263p|h264|mpeg4|t140)' incompatible with our capability '0x8 (alaw)'.
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: REJECT
  Timestamp: 00060ms  SCall: 05018  DCall: 00001 [xx.xx.xx.xx:4569]
  CAUSE           : Unable to negotiate codec
  CAUSE CODE      : 58

Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 002 Type: IAX     Subclass: ACK    
  Timestamp: 00060ms  SCall: 00001  DCall: 05018 [xx.xx.xx.xx:4569]

By: Bruno Enten (benten) 2009-11-09 09:40:14.000-0600

That may have something to do with :

r227580 | tilghman | 2009-11-04 14:05:12 +0000 (Wed, 04 Nov 2009) | 3 lines

Expand codec bitfield from 32 bits to 64 bits.
Reviewboard: https://reviewboard.asterisk.org/r/416/

By: Chris Stone (habile) 2009-11-09 10:48:05.000-0600

Yes I suspect the mask where the capabilities are ANDed with 0xFFFF but I am not a programmer ... the closest I get is using programmer mode on Windows Calc.exe

By: Tilghman Lesher (tilghman) 2009-11-09 11:16:32.000-0600

habile: what version of Asterisk is on the other side?  Is it a 1.2 release, like benten?

By: Chris Stone (habile) 2009-11-09 11:21:53.000-0600

I'm afraid I'm not sure on that as this is the service provider's. However, I get the same issue if I try to use an IAX client such as Zoip. Thanks.

By: Digium Subversion (svnbot) 2009-11-09 11:23:19.000-0600

Repository: asterisk
Revision: 228979

U   trunk/channels/iax2-parser.c

r228979 | tilghman | 2009-11-09 11:23:18 -0600 (Mon, 09 Nov 2009) | 4 lines

Don't try to convert a 64-bit integer, where only a 32-bit integer is stored.
(closes issue ASTERISK-15089)
Reported by: habile