Am 12.01.2011 11:37, schrieb Duncan Turnbull:
> Hi there
>
> I have two different asterisk systems (both 1.4) whose dtmf tones are not being picked up by a particular conference system users are dialling into. I can call myself with the phones and hear the tones, but I am guessing perhaps they are too short or somehow different. I have looked and looked but can’t nail down the reason. I don’t believe this is a general issue, rather some specific conference systems that they need.
>
> I am sure I saw this covered a few years ago but can’t find it in the lists.
>
> The phones and the system are using rfc2833 and either alaw or ulaw, I have stayed away from in band dtmf, but may need to consider it. They also use *1 to turn on call recording and I am not sure how that will go with inband.
>
> Another 1.6 system has no problem with being detected and it uses SIP trunks from the same supplier as the customer.
>
> The first system is a 1.4.38 box, it has sip trunks as the primary outbound route, the secondary route is iax to another box then via analogue lines. Almost all the handsets are sip and a re a mix of polycom and yealink.
>
> The sip trunks routed out through the iax link via analogue lines seem to work okay too. I am wondering if the iax handling of dtmf matches whatever the far end is expecting a little better
>
> For now I have routed everything via the iax / analogue lines which may cause some problems in terms of line availability but gets past the issue. I am considering upgrading the box to 1.6 as the working one is 1.6
>
> The other box is a digium AA50 appliance so I can’t do much with it, other than find the right settings.
>
> I have on the first one
> relaxdtmf=yes - relates to old issues too as far as I can tell
> rfc2833compensate=yes - this only appears to matter for inbound
>
> I’m not sure these do anything useful
>
> > From what I can tell it could be the toneduration, but don’t know what it should be, and while technically its probably the IVR being fussy that doesn’t help me and I want to see why one system works and one doesn’t
>
> This is dtmf debug from an iax handset sending digit 4
>
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-00000639 to write format slin
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 160 sample intervals
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:5297 ast_channel_start_silence_generator: Started silence generator on ‘SIP/xtreme-00000639′
> [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2796 ast_rtp_raw_write: Difference is 1736, ms is 237
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 0 sample intervals
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:5310 ast_channel_stop_silence_generator: Stopped silence generator on ‘SIP/xtreme-00000639′
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-00000639 to write format alaw
> [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 1713844722 to 565606422 due to a source change
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF begin on channel (IAX2/419-13088)
> [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update
> [Jan 12 23:13:55] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-00000639
> [Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 565606422 to 226872656 due to a source change
> [Jan 12 23:13:56] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF end on channel (IAX2/419-13088)
> [Jan 12 23:13:56] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update
> [Jan 12 23:13:56] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-00000639
> [Jan 12 23:13:56] DEBUG[8717]: res_features.c:1399 feature_interpret: Feature interpret: chan=IAX2/419-13088, peer=SIP/xtreme-00000639, code=4, sense=1
>
> I will get a sip dump but am remote for now and don’t have sip access
>
> All pointers and knowledge appreciated
>
> Cheers Duncan
As far as I can remember you should take a look at the used codec and
this here:
http://www.voip-info.org/wiki/view/Asterisk+sip+dtmfmode

Some codecs do not feel happy with some seetings for dtmfmode. Perhaps
you may comapre these on your 2 boxes.

Hi there

I have two different asterisk systems (both 1.4) whose dtmf tones are not being picked up by a particular conference system users are dialling into. I can call myself with the phones and hear the tones, but I am guessing perhaps they are too short or somehow different. I have looked and looked but can’t nail down the reason. I don’t believe this is a general issue, rather some specific conference systems that they need.

I am sure I saw this covered a few years ago but can’t find it in the lists.

The phones and the system are using rfc2833 and either alaw or ulaw, I have stayed away from in band dtmf, but may need to consider it. They also use *1 to turn on call recording and I am not sure how that will go with inband.

Another 1.6 system has no problem with being detected and it uses SIP trunks from the same supplier as the customer.

The first system is a 1.4.38 box, it has sip trunks as the primary outbound route, the secondary route is iax to another box then via analogue lines. Almost all the handsets are sip and a re a mix of polycom and yealink.

The sip trunks routed out through the iax link via analogue lines seem to work okay too. I am wondering if the iax handling of dtmf matches whatever the far end is expecting a little better

For now I have routed everything via the iax / analogue lines which may cause some problems in terms of line availability but gets past the issue. I am considering upgrading the box to 1.6 as the working one is 1.6

The other box is a digium AA50 appliance so I can’t do much with it, other than find the right settings.

I have on the first one
relaxdtmf=yes - relates to old issues too as far as I can tell
rfc2833compensate=yes - this only appears to matter for inbound

I’m not sure these do anything useful

From what I can tell it could be the toneduration, but don’t know what it should be, and while technically its probably the IVR being fussy that doesn’t help me and I want to see why one system works and one doesn’t

This is dtmf debug from an iax handset sending digit 4

[Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-00000639 to write format slin
[Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 160 sample intervals
[Jan 12 23:13:55] DEBUG[8717]: channel.c:5297 ast_channel_start_silence_generator: Started silence generator on ‘SIP/xtreme-00000639′
[Jan 12 23:13:55] DEBUG[8717]: rtp.c:2796 ast_rtp_raw_write: Difference is 1736, ms is 237
[Jan 12 23:13:55] DEBUG[8717]: channel.c:1986 ast_settimeout: Scheduling timer at 0 sample intervals
[Jan 12 23:13:55] DEBUG[8717]: channel.c:5310 ast_channel_stop_silence_generator: Stopped silence generator on ‘SIP/xtreme-00000639′
[Jan 12 23:13:55] DEBUG[8717]: channel.c:3372 set_format: Set channel SIP/xtreme-00000639 to write format alaw
[Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 1713844722 to 565606422 due to a source change
[Jan 12 23:13:55] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF begin on channel (IAX2/419-13088)
[Jan 12 23:13:55] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update
[Jan 12 23:13:55] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-00000639
[Jan 12 23:13:55] DEBUG[8717]: rtp.c:2130 ast_rtp_change_source: Changing ssrc from 565606422 to 226872656 due to a source change
[Jan 12 23:13:56] DEBUG[8717]: channel.c:4610 ast_generic_bridge: Got DTMF end on channel (IAX2/419-13088)
[Jan 12 23:13:56] DEBUG[8717]: rtp.c:2118 ast_rtp_new_source: Setting the marker bit due to a source update
[Jan 12 23:13:56] DEBUG[8717]: channel.c:4927 ast_channel_bridge: Bridge stops bridging channels IAX2/419-13088 and SIP/xtreme-00000639
[Jan 12 23:13:56] DEBUG[8717]: res_features.c:1399 feature_interpret: Feature interpret: chan=IAX2/419-13088, peer=SIP/xtreme-00000639, code=4, sense=1

I will get a sip dump but am remote for now and don’t have sip access

All pointers and knowledge appreciated

Cheers Duncan

Hello!
Ater several successful SRTP-enabled calls with SRTP set to Mandatory,
asterisk starts to give the following warnings in Log:

WARNING[13714] res_srtp.c: SRTP unprotect: authentication failure
(continiously)

and client hears no sound. After i restart the client program it works
fine again for a while. Then the same warning again.

Asterisk 1.8.1.1, RealTime engine, sip peer has encrytion->yes
The client program is CSipSimple on Android

Here are some log file traces:
Peer 0010101 is calling some number that is routed to context a2billing

[2010-12-23 11:06:22] DEBUG[5941] sip/sdp_crypto.c: local_key64
3gWGFJAffj4Pn393BUPwe3/wOMx5/ndZyPtfno7L len 40
[2010-12-23 11:06:22] DEBUG[5941] sip/sdp_crypto.c: SRTP policy activated
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: Processing media-level
(audio) SDP a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:0VyG/fnup0U9qDoTGlWvVuE5yAef5MfYU6F67oI+… OK.
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: We’ve already processed
a crypto attribute, skipping ‘crypto:2 AES_CM_128_HMAC_SHA1_32
inline:5X/Zqep5tNdDGFhOY1//VFQ7diCCH1Y1FUKgYXLp’
…
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: *** Our native formats
are 0×100 (g729)
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: *** Joint capabilities
are 0×100 (g729)
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: *** Our capabilities are
0x10e (gsm|ulaw|alaw|g729)
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: *** AST_CODEC_CHOOSE
formats are 0×100 (g729)
…
010-12-23 11:06:22] DEBUG[5941] chan_sip.c: build_route: Contact hop:

[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: Incoming INVITE with
‘timer’ option supported and “Session-Expires” header.
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: Session-Expires: 1800
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: Received Min-SE: 90
…
[2010-12-23 11:06:22] DEBUG[5931] chan_sip.c: -REALTIME- peer built.
Name: 0010101. Peer objects: 660
[2010-12-23 11:06:22] DEBUG[5931] netsock2.c: Splitting ’78.84.207.114′ gives…
[2010-12-23 11:06:22] DEBUG[5931] netsock2.c: …host ’78.84.207.114′
and port ‘(null)’.
[2010-12-23 11:06:22] DEBUG[5931] chan_sip.c: Not an IPv4 nor IPv6
address, cannot get port.
[2010-12-23 11:06:22] DEBUG[5931] chan_sip.c: Not an IPv4 nor IPv6
address, cannot set port.
[2010-12-23 11:06:22] DEBUG[5931] chan_sip.c: -REALTIME- loading peer
from database to memory. Name: 0010101. Peer objects: 660
[2010-12-23 11:06:22] DEBUG[5931] chan_sip.c: Destroying SIP peer 0010101
[2010-12-23 11:06:22] DEBUG[5931] chan_sip.c: -REALTIME- peer
Destroyed. Name: 0010101. Realtime Peer objects: 659
[2010-12-23 11:06:22] DEBUG[5931] devicestate.c: Changing state for
SIP/0010101 – state 1 (Not in use)

is this normal here? peer destroyed?

[2010-12-23 11:06:22] DEBUG[5931] devicestate.c: device ‘SIP/0010101′ state ’1′
[2010-12-23 11:06:22] WARNING[8264] res_srtp.c: SRTP unprotect:
authentication failure
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: = Looking for  Call ID:
2WZXYS-qTPPfXylUor4tckg25TetmIVP (Checking From) –From tag
50FYKcXAUIrUwsIpR5xm9pjrSrMaDglb –To-tag as46be1cdb
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: **** Received ACK (6) -
Command in SIP ACK
[2010-12-23 11:06:22] DEBUG[5941] chan_sip.c: Stopping retransmission
on ’2WZXYS-qTPPfXylUor4tckg25TetmIVP’ of Response 20465: Match Found
[2010-12-23 11:06:22] WARNING[8264] res_srtp.c: SRTP unprotect:
authentication failure
[2010-12-23 11:06:22] WARNING[8264] res_srtp.c: SRTP unprotect:
authentication failure
[2010-12-23 11:06:22] WARNING[8264] res_srtp.c: SRTP unprotect:
authentication failure
[2010-12-23 11:06:22] WARNING[8264] res_srtp.c: SRTP unprotect:
authentication failure
[2010-12-23 11:06:22] WARNING[8264] res_srtp.c: SRTP unprotect:
authentication failure
[2010-12-23 11:06:22] WARNING[8264] res_srtp.c: SRTP unprotect:
authentication failure

On Wed, Dec 22, 2010 at 04:48:33PM +0100, Giorgio Incantalupo wrote:
> Hi all,
>
> thanks for answering.
>
> You all are right but I do not really need the codec because my phones
> and my Voip lines are all working using g729.

I assume you do not need it as you stated. In this case, configure your
VoIP lines not to use g729. Problem solved.

> Asterisk is working fine
> without transcoding as well…..the problem is my CLI is flooded with
> messages like:
> WARNING[7831] translate.c: No translator path from alaw to unknown
> which are quite annoying…aren’t they?

Asterisk is complaining because it *does* need a g729 codec.

> Should I pay to avoid a CLI message….?

Patching it out should be simple. But you’d still miss the audio.

> That doesn’t sound fair to me.

As I just mentioned: you’d be missing some audio.

The Asterisk Development Team is pleased to announce the release of
DAHDI-Linux and DAHDI-Tools version 2.4.0.

DAHDI-Linux 2.4.0, DAHDI-Tools 2.4.0, and DAHDI-Linux-Complete are
available for immediate download at:
http://downloads.asterisk.org/pub/telephony/dahdi-linux
http://downloads.asterisk.org/pub/telephony/dahdi-tools
http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete

In addition to several bug fixes, the most significant changes from the
2.3.0 release are:

General DAHDI Changes:

* Added DAHDI_MAINT_ALARM_SIM maintenance mode for drivers that
support alarm simulation (wct4xxp). This is only used by
dahdi_maint and doesn’t change the ABI.

* Span callbacks are moved out of the dahdi_span structure potentially
saving memory when a single driver implements multiple spans.

Updated Drivers:

* wctdm24xxp, wcte12xp: Fix bug when moving to memory mapped registers
where the interrupt handler was run twice for every interrupt.

* wctdm24xxp, wcte12xp: Processing moved back to interrupt handler.
(Closes issue #17289 Reported by alecdavis)

* wctdm24xxp, wcte12xp: Update VPMADT032 firmware to 1.25. Contains
improvements to prevent loss of convergence when signal levels go
over a certain threshold and for handling line condition changes.

* wctdm24xxp: Fix race conditions/improvements in FXS line feed register
handling.
(Closes issues #17724 and #17764. Reported and patched by alecdavis)

* wctdm24xxp: Added “companding” module parameter to replace
“alawoverride”. When BRI modules are installed on a Hx8 board alaw is
the default companding so change the semantics to just allow the
companding to be forced as opposed to overriding a default. The
default is “auto” which means alaw if there are BRI modules, otherwise
ulaw.

* wctdm24xxp: Set ‘spantype’ for digital spans so that they can be
displayed with dahdi_scan.

* wcte12xp: dahdi_cfg does not need to be called twice when using RBS
signalling.

* wcte12xp: Loopback module parameter removed since ‘dahdi_maint’ can
now put the spans in digital loopback.

* wct4xxp: Add ‘latency’, ‘max_latency’, and ‘ms_per_irq’ module
parameters to set expected latency conditions when using Gen5
firmware.

* wct4xxp: Added support for network loopback modes via dahdi_maint.

* wct4xxp: Which span is providing card timing is now exported via
sysfs.

* wcb4xxp: Fixed pulse mask for improved TBR3 compliance.

* wcb4xxp: Added pci-ids for Junghanns PCI-E cards.

* wcb4xxp: Added ‘companding’ module parameter.

* wcb4xxp: Fixed bug when using automatic timing sync.

* wcb4xxp: Which span is providing card timing is now exported via
sysfs.

* wctdm: Added configurable debounce to support old rotary phones.
(Closes issue #16339. Reported by alecdavis patch by tilghman.)

* xpp:
FXS: support VMWI config from Asterisk >= 1.6.1
PRI:
- PRI Astribanks always sync AB (and independent)
- don’t send “duplicates” in E1 as in D4
- Reduce noise at E1 startup.
- T1 CAS fixes.
PIC 4 rev. 7381: fix T1 returning signaling register in non-CAS

Changes to dahdi-tools:

* dahdi_maint: Added support for simulating alarm conditions.

* dahdi_scan: Report more detailed alarm information.

* xpp_fxloader:
- Load firmware in the background
- Support 1163 twinstar devices
- A delay loop for older kernels (e.g. 2.6.18)

* astribank_is_starting does not depend on libusb.

* Allow using CONNECTOR/LABEL in genconf_parameters for pri_termtype

For a full list of changes in these releases, please see the ChangeLogs at
http://svn.asterisk.org/svn/dahdi/linux/tags/2.4.0/ChangeLog and
http://svn.asterisk.org/svn/dahdi/tools/tags/2.4.0/ChangeLog

Issues found in these releases can be reported at http://issues.asterisk.org

Thank you for your continued support of Asterisk!