ASTERISK-10879: chan_mobile does not recognize dtmf together with Authenticate or DISA

[Home]

Summary: ASTERISK-10879: chan_mobile does not recognize dtmf together with Authenticate or DISA

Reporter: Thomas Baumann (bt047265) Labels:

Date Opened: 2007-11-25 08:42:05.000-0600 Date Closed: 2009-07-31 09:11:07

Priority: Minor Regression? No

Status: Closed/Complete Components: Addons/chan_mobile

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) incoming_mobile_authenticate.txt
( 1) incoming_mobile_to_sip_extension.txt
( 2) incoming_sip_authenticate.txt
( 3) incoming-3.wav

Description: Hello,

chan_mobile is configured according to the documentation. Incoming and outgoing calls are working via the new channel "Mobile".

Mobile.conf:

[adapter]
id=stick1
address=00:08:F4:16:3A:E2
[SGH-F200]
;address=00:1D:25:73:0E:76
address=00:1B:59:14:77:38
port=4
context=incoming_mobile
adapter=stick1
dtmfskip=50

This dialplan was added to the extensions.conf:

[incoming_mobile]
exten => _!,1,Answer()
exten => _!,n,Wait(1)
exten => _!,n,Verbose(${EXTEN})
exten => _!,n,Verbose(${CALLERID})
exten => _!,n,Authenticate(1234)
exten => _!,n,Background(vm-enter-num-to-call)
exten => _!,n,DISA(no-password,phones,"sipgate" <7001>)

No DTMF tones are regocnized by the Authenticate function. If the same context is assigned to the SIP channel Authenticate and DISA is working.

Attached the output of /var/log/asterisk/full for:

- incoming mobile authenticate
- icoming mobile to SIP extension
- incoming SIP authenticate

If the incoming call from the mobile is directly routed to an SIP extension, DTMF is sended to the SIP extension.

Comments: By: Thomas Baumann (bt047265) 2007-11-25 09:15:30.000-0600

In the 2 working cases this output is maybe significant:

[Nov 25 16:04:17] DEBUG[17318] channel.c: Set channel SIP/1837993-08216e98 to read format ulaw
[Nov 25 16:04:17] DEBUG[17318] channel.c: Set channel SIP/1837993-08216e98 to write format gsm

The format is set to "read" and "write". In the not working case it is set to "write" only.
By: Thomas Baumann (bt047265) 2007-11-28 17:11:33.000-0600

Tested with this SVN Revision: 89698, problem still exists.
By: Sabin (binsa) 2007-12-10 11:04:22.000-0600

Yes, from some revisions it is true at all, not only with Authenticate or DISA
By: Thomas Baumann (bt047265) 2007-12-10 11:11:15.000-0600

I am not sure what to do with this. It looks like that this is a known restriction for chan_mobile. Which revisions are working ?
By: jmls (jmls) 2008-02-06 04:13:09.000-0600

can you test against the latest trunk please
By: Pábulo Silva (pabulo) 2008-02-11 12:45:39.000-0600

I tried to use Read, WaitExten, DISA and Background, but only background receives the dtmf (one digit) correctly, the other applications didn't work. I tried to monitor (record) the sound of answered channel and no sound is captured.
I used the last trunk and tried also with 1.6 beta 2 but no luck.
By: Sergey Vladimirov (svlad1983) 2008-03-31 07:51:43

I used latest trunk for asterisk 1.6 and Sony Ericcson w800i, but no DTMF accepted by Read application.
If I press buttons while talking to SIP client DTMF tones are being sent.

is there any work around?
By: fernando aversa (aversa) 2008-04-07 17:53:36

I used the latest trunk for asterisk 1.6 and a Nokia 2630. I call the Nokia 2630
and asterisk anwser, DTMF tones are detected while asterisk plays an announcement.
Nothing is accepted by a Read() command.

I noticed that in
main/channel.c, in the function:
static struct ast_channel *ast_waitfor_nandfds_classic
waits until timeout (10 seconds in my case) in this line:

res = poll(pfds, max, rms);

and nothing is detected.

But if an announcement is played, the same line correctly reports the DTMF tones.

By: BrettS (ughnz) 2008-05-18 02:58:49

I am also having this problem with DISA where no DTMF is being recognized by the DISA application.

Also the DISA application will not release the mobile channel after the cellphone has hung up and only a total asterisk restart will terminate the stuck DISA app and release the mobile channel.

In case it helps I get this error in the log:

WARNING[2918] channel.c: Unable to write to alert pipe on (null), frametype/subclass 4/1 (qlen = 0): Bad file descriptor!
By: Matthew Nicholson (mnicholson) 2009-01-21 17:05:04.000-0600

I am going to try to reproduce this issue on a blackberry 8830. Stand by.
By: jongerenchaos (jongerenchaos) 2009-02-02 12:29:21.000-0600

The DTMF tones are accepted with the background command,but with an small delay.

I hope there is a patch avalilble soon, because this is a problem in all the chan_mobile versions with all the versions of bluez.
By: nixon nixon (nixon) 2009-02-10 19:43:52.000-0600

I'm waiting for decision of this DTMF problem also.
I have Nokia 6230i, Nokia 6021 and dongle at chip BCM2045A.
Asterisk 1.6.1-rc1 built by mockbuild @ x86-3.fedora.phx.redhat.com on a x86_64 running Linux on 2009-02-09 05:58:36 UTC
Fedora10 2.6.28.5 #4 SMP Sat Feb 14 08:27:32 EET 2009 x86_64 x86_64 x86_64 GNU/Linux
bluez-4.30

By: Matthew Nicholson (mnicholson) 2009-02-18 18:16:12.000-0600

This error appears to be caused because of the way chan_mobile handles audio data. Currently chan_mobile only reads audio from the phone when it writes audio to the phone. This is why it works with background, but not with DISA or Authenticate. I am working on a fix.
By: Matthew Nicholson (mnicholson) 2009-02-19 17:09:20.000-0600

I just uploaded the audio1.diff patch. Please test this patch and see if it resolves your issue.
By: nixon nixon (nixon) 2009-02-20 07:24:24.000-0600

Delay of voice is the best now! Thnxs!
But DTMF...
Voice is passed splendidly, but as soon as dtmf tones, each digit is torn to fragments and heard as the interrupted parts - by ear. Therefore with any 'dtmfskip'(20,40,50,70,100,150,200,400,500), the best from my attempts is with dtmfskip=50:
-- Called caca_gate/3804447221992228
originally was 380445721928
In addition, if send many tones from asterisk to cellular there are enormous interruptions between sending of digits and with every next digit an interruption is multiplied.
By: jongerenchaos (jongerenchaos) 2009-02-20 07:33:23.000-0600

@nixon. Did you use the newest version of bluez-4.30 ?? Bluez has also an improvement audio solution with this new version. Maybe that will tacle the problem.
By: nixon nixon (nixon) 2009-02-20 08:04:41.000-0600

yes i have already
http://bugs.digium.com/view.php?id=11368#99864

By: jongerenchaos (jongerenchaos) 2009-02-20 12:48:16.000-0600

Patch works great!! No problems for now, DMTF detection works also!
By: Matthew Nicholson (mnicholson) 2009-02-20 13:12:24.000-0600

@nixon
I do not know if there is much I can do about sending tones from asterisk to the phone, asterisk basically sends the phone a command, and the phone generates the tone.

Can you give me more information about your dtmf reception problems. I may be able to fix those.

@jon
Glad to hear it.
By: BrettS (ughnz) 2009-02-20 18:10:24.000-0600

Which version of addons do I apply the patch too?

Tried with the 1.6.0.1 version and it failed.
By: Matthew Nicholson (mnicholson) 2009-02-23 09:33:21.000-0600

Test with the trunk version of addons.
By: nixon nixon (nixon) 2009-02-25 10:35:51.000-0600

I uploaded incoming-3.wav/ this is record of channel of incoming tones that not recognize properly as I wrote at http://bugs.digium.com/view.php?id=11368#100441
may be this help.
P.S.
[adapter]
id=asus
address=00:02:72:13:9C:D7
[Nokia6021]
address=00:14:A7:56:8A:C0
adapter=asus
port=13
context=incoming-mobile
dtmfskip=200
By: Matthew Nicholson (mnicholson) 2009-02-26 09:27:10.000-0600

how did you produce this recording?
By: nixon nixon (nixon) 2009-02-26 11:37:32.000-0600

by exten => s,n,Record(incoming-%d:wav)
By: Matthew Nicholson (mnicholson) 2009-02-26 16:35:32.000-0600

I reproduced your experiment here, and I initially got the same results. When I stripped out dtmf processing, the recording of the tones sounded perfect. This means that chan_mobile is accurately passing the tones into the dtmf processing engine, and the artifacts in your recording are actually the dtmf processing engine's attempts to strip out the dtmf tone from the audio stream. I will look into this further, but basically this means the problems are in the dtmf detection code rather then in chan mobile.

You may see similar issues with tones if you test with a sip phone using inband dtmf.
By: nixon nixon (nixon) 2009-02-26 19:39:03.000-0600

Thank you for reproduce.
I have tested with "dtmfmode=inband" already, but not see of DTMF degradation.
May be passing the tones out of chan_mobile will did path through? Or by rfc2833 instead? ...I don't know how now.
By: nixon nixon (nixon) 2009-02-27 07:32:07.000-0600

I continue my research, because dtmf does not function still. However much more intent testing resulted to discovery. I paid attention that seemed a chance at first, but now became statistics, as it repeats oneself all time... At night dtmf detection are 100% and sound on the side of asterisk is audible othergates. It is possible it would be to decide that a problem is in the cellular operator, but it is and so and not so simultaneously. My day calls on other subscribers, where the input of dtmf is required pass splendidly. I will upload my tests in the near future.
By: Francisco Ceballos Peniche (franciscoce) 2009-03-09 09:26:50

Can somebody confirm if this patch is ok? I cannot compile trunk version of addons on Fedora 9 or 10.
thanks
By: Alexander Zakharov (alexz) 2009-03-30 15:52:58

I did try the patch with Asterisk 2.6.1-rc03 and Addons 2.6.1-rc03 and seems to me that issue is still here - I can see DTMF digits coming during announcement play, but Authenticate is still deaf with regard to incoming DTMF. Did I miss something somewhere? Can somebody confirm that patch fixed the issue? I am using Ubuntu 9.04 beta with Bluez 4.32 - sound quality is perfect, no delays, no noise, just perfect conversation. Spent yesterday almost half an hour on a outbound call to another cell and not a sign of any issue. Small observation though - depending on which party hangs first, local cell phone may disconnect/reconnect. Anybody else observes the same?

Which part of the patch suppose to fix inbound DTMF problem? I am willing to dig the code and see where extra changes should be done.
By: Matthew Nicholson (mnicholson) 2009-03-30 17:22:11

The patch should fix the inbound audio issue, and this should also fix the DTMF issue. What do you mean when you say you can see the DTMF digits coming in? It sounds like you are not actually testing with the patch. This patch has been applied to addons-trunk, test with that.

The hangup issue is issue 10824.
By: Alexander Zakharov (alexz) 2009-04-01 00:32:20

Sorry, I wasn't specific - it didn't recognize tones with Authenticate and DISA, as original bug report states. Granted, I did apply patch to addons 1.6.1 rc3 and used it together with asterisk 1.6.1 rc3. As for the current trunk version, patch fails to apply with 'Reversed (or previously applied) patch detected!' message. If I go ahead with 'y', then it fails to apply all the changes. After that compile fails. So, my question is - which exact addons version I should use? (Having in mind that CURRENT/TODAY'S trunk is not suitable for this patch). And a separate (very important to me) question - which release of addons this fix will appear in?
By: Alexander Zakharov (alexz) 2009-04-01 01:14:20

Update - trunk version (asterisk + addons) crashes on outbound chan_mobile call :(
with screen full of garbage (asterisk -vvvvvr), something like this:

-- Executing [s@macro-dialout-trunk:17] GotoIf("DAHDI/1-1", "0?bypass,1") in new stack
-- Executing [s@macro-dialout-trunk:18] GotoIf("DAHDI/1-1", "1?customtrunk") in new stack
-- Goto (macro-dialout-trunk,s,21)
-- Executing [s@macro-dialout-trunk:21] Set("DAHDI/1-1", "pre_num=AMP:MOBILE/g1/") in new stack
-- Executing [s@macro-dialout-trunk:22] Set("DAHDI/1-1", "the_num=OUTNUM") in new stack
-- Executing [s@macro-dialout-trunk:23] Set("DAHDI/1-1", "post_num=") in new stack
-- Executing [s@macro-dialout-trunk:24] GotoIf("DAHDI/1-1", "1?outnum:skipoutnum") in new stack
-- Goto (macro-dialout-trunk,s,25)
-- Executing [s@macro-dialout-trunk:25] Set("DAHDI/1-1", "the_num=6137978600") in new stack
-- Executing [s@macro-dialout-trunk:26] Dial("DAHDI/1-1", "MOBILE/g1/6137978600,300,") in new stack
-- Called g1/6137978600
øÿøÿøÿðÿðÿðÿðøÿØÿàÿðøÿøÿøøÿðÿøÿøÿøÿøÿøÿðÿèÿèÿððÿèÿèÿðÿàÿèðÿðÿøøøøèÿèøÿðÿðÿØøÿøÿèðÿèÿøÿèÿøÿðÿðÿøÿèÿøÿøÿððÿèÿøÿðÿøÿøøÿðÿèÿøÿàÿðÿøøÿðÿððÿèðÿðÿøÿøÿøÿðøÿøðÿèÿèÿàÿðÿðÿøøÿðÿðÿèÿèøÿðÿèÿàÿèÿðÿøøÿøÿèÿðÿøÿøøÿøÿøÿðÿøÿðèÿøÿøÿðÿØÿØÿð ((øÿøÿðÿøÿøÿèÿðøÿðÿøÿøÿðÿøÿøÿøÿøøÿèÿàÿðøÿèÿèÿèÿðÿø
ðÿøÿøÿðÿøÿðÿðÿøÿøÿøÿøÿàÿ and so on...
By: Matthew Nicholson (mnicholson) 2009-04-01 08:13:10

The patch is already in addons-trunk. Once the code is stable, it will go into 1.6.0 and 1.6.1. Please test with addons-trunk.

That garbled output may not be coming from chan_mobile. If you are experiencing a crash, please follow the instructions in doc/backtrace.txt and open a new bug for the crash.
By: Alexander Zakharov (alexz) 2009-04-02 11:10:34

Ok. Here is the layout:

1) Release Asterisk and release Addons - can't apply patch
2) Asterisk 1.6.1 rc3 and Addons 1.6.1 rc3 - apply patch, compilable, but issue still here
3) Trunk Asterisk and trunk Addons - asterisk crashes on any incoming/outgoing call
4) Asterisk 1.6.1 rc3 and trunk Addons - with some changes (not related to chan_mobile) compilable, but Asterisk is in a dead loop on start with code 127
5) Asterisk 1.6.1 rc3 and Addons 1.6.1 rc3 with complete replacement of chan_mobile.c taken from addons trunk - compilable, but mobile call hangs up right from the beginning in both directions

Seems to me that I tried all possible combinations, so my question will be the following:

Anybody who tested and proved it working - can you please be so kind to provide me with exact revisions (trunk or stock) of Asterisk, Addons and Dahdi that you used? I need to figure out exact combination.

I am using Ubuntu Server 9.04 with bluez 4.32 (it's been tested with stock Asterisk 1.6.0.6, Addons 1.6.0, Dahdi 2.1.0.4, Tools 2.1.0.2) and everything is perfect except DTMF detection in Authenticate and DISA.

Thanks in advance.
By: Matthew Nicholson (mnicholson) 2009-04-02 15:53:29

alexz,

Please open a bug with the information from the crash in your "layout 3". I am not experiencing this problem with asterisk trunk, addons trunk, and bluez 4.33 on debian lenny (v5.0).
By: Alexander Zakharov (alexz) 2009-04-03 14:26:57

Before reporting a bug I would like to try your setup - I really need to make this whole thing working for the proof of concept purposes. My choice of Ubuntu was mainly because of ease of use and installation - but I am not hard coded on it and Debian should work as well. Another thing is that looks like Lenny/bluez4.33 ast/addons trunk is your verified test environment - so in case I'll encounter road blocks we'll be on the same page. Few questions though (if you don't mind):

1) Are you trying to stay with latest bluez? 4.33 looks very new, and 4.34 is released (for some weird reasons I couldn't compile it (4.34) on Ubuntu)

2) Which rev of Dahdi / Dahdi tools are you using?

Thanks in advance.
By: Matthew Nicholson (mnicholson) 2009-04-03 14:55:59

I am not using dahdi. I upgraded to bluez 4.34 today, and yes I am trying to stay with the latest.

Are you doing any SMS stuff with chan_mobile?
By: Alexander Zakharov (alexz) 2009-04-03 16:46:02

Strange... I wasn't able to compile it yesterday - something to do with libsbc.lo that somehow wasn't compiled and as a result failed linking. On the other hand 4.30,32,32,33 were OK.

A reason behind why I would like to have chan_mobile with ANY legit hardware (dahdi) (OpenVox in our case) is that we would like to have stable and proven clock source, not dahdi_dummy or something else (which generally speaking most of the cases is based on hardware RTC or OS clock tick, which in turn wouldn't give you precise clocking). By the way, this might be a reason why some users complained in a past about increasing audio delay during the conversation. I am not completely positive with this regard, but it's more likely the case. Actually I am surprised why nobody up till today did come up with cheap solution for the timing source. From my telco background standpoint I would use hardware clock source rather then rely on OS clocking resources. Network based clock source is good for general purposes, but I wouldn't use it for voice communications. When it comes to DTMF decoding, it's a real challenge in wireless world. First of all, DTMF in this area does exist solely for user audio confirmation purposes, and not as an engine to deliver DTMF digits (digits are delivered over message link, not voice channel). As a result, telco provider can simply slightly alter each tone frequencies, just enough to be out of 5% deviation allowed by standard, and we will not be able to detect a damn thing, unless our DTMF Goerzel algo will be tuned correspondingly, or we'll have a way to implement some sort of 'learning' mode and alter corresponding base frequencies for the algorithm, but then again, we might screw up other DTMF decoding users. My only hope is that telco on their switches is using the same hardware for encoding DTMF tones both directions (cellular and PSTN). At least on DMS switches from Nortel it's done that way. Simple example - I am in Ottawa, Canada and I am with Rogers. When I started to play with chan_mobile half a year ago (just for try), it turned out that locally in Ottawa DTMF tones were absent AT ALL between Rogers cellular customers. It did work though if I will move to the long distance zone, or will place a call to Bell Canada customer (everything was fine on calls to the land lines - but they had to, otherwise none of the IVR applications would work). Took me 3 month and 10 or so tech support tickets before they fixed it (excuse was that their Ericsson switch did luck certain hardware (read - DTMF encoders). Even now, when it's fixed, it's crappy anyways. If you noticed, there is some reason behind Rogers customer service is based on voice recognition rather then 'push button' conception. I am dying to see how asterisk will handle this very distorted and crappy tones. I am not a musician, but to my ear they are sound slightly wrong. I spent at some point few years ago great deal of time with variety software based DTMF decoding algos and can distinguish between good tones and distorted ones. But then again, it's Rogers. I might sound paranoic, but I think that the best way to accomplish the job would be:

1) Have small applet written for the cell phone itself, which on demand (from phone book for example, or from app) will play sequence of mp3 DTMF digit files. DTMF dialer app does exist for many cell phones, and in a sense replicates old fashion DTMF dialer, when you can approach the regular phone and just 'play' the number - speaker to mike.

2) Something more advanced - together with placing a call send simultaneous SMS with destination number sequence. I didn't try it personally, but I think it's possible to get SMS notification while in voice call - also requires small app on a cell phone.

I didn't play around with SMS, because all phones that I have in hand do report no support for SMS via mobile show devices.

I will try Lenny from scratch next week and will immediately report the results.

I think that both approaches are doable, nowadays almost each and every cell phone provider gives you some sort of programming capability.
By: Matthew Nicholson (mnicholson) 2009-04-03 17:02:56

I did have some problems compiling bluez 4.34. I had to #include <signal.h> in the file that was failing. Interesting commentary on the DTMF reception issues. The problem with Authenticate and DISA is not related to any network or handset problems though. Also the increasing latency was a bug in the code, not with the timing source AFAIK. Still interesting though.

I was curious about the SMS stuff in relation to your crashes. I think your crashes may be a bug in chan_mobile. Please open a new bug.
By: Matthew Nicholson (mnicholson) 2009-04-08 14:28:17

The crash should be fixed in the latest addons trunk svn code. Please test with that and let me know if you are still seeing DTMF issues.
By: Francisco Ceballos Peniche (franciscoce) 2009-04-09 11:12:50

Some minor issue observed: DTMF works fine with background app EXCEPT when the very first call to asterisk/chan_mobile was made. In that case, DTMF was not recognized. I need to hangup and call again, then DTMF works great.
Another comment: In Mexico IUSACELL CDMA provider does not send DTMF. TELCEL GSM does. Thank you all for this remarkable effort.
By: Matthew Nicholson (mnicholson) 2009-04-09 11:53:05

DTMF seems to work fine on the first call for me with app_read.

Here Sprint (CDMA) does send DTMF, so it must not be specific to the network technology.

And you are quite welcome.

I think I have done just about every thing I can on this bug. I will be closing it soon if there are no objections.
By: Tom MacLean (tmaclean) 2009-04-13 20:33:27

I am still not able to authenticate. Before the patch I could not see any read transactions during the authenticate, and with the patch, I can see reading going on -- a marked improvement, however ... still no DTMF. I'll try updating both ast and ast-addons.

Current:
bluez 4.32
ast trunk 186537
ast-addons trunk 844
By: Matthew Nicholson (mnicholson) 2009-04-14 13:07:27

tmaclean,

If you call your cellphone from a land line and push DTMF keys, can you hear the tones?
By: Matthew Nicholson (mnicholson) 2009-04-21 13:23:50

I will be closing this issue soon if there are no further objections.
By: Tom MacLean (tmaclean) 2009-04-21 14:15:45

Hi Mnicholson,

Yes, there are DTMF tones. When I use the dialplan shown in the bug report but reverse the Background and Authenticate statements, I can see the DTMF tones reported in the CLI during background (in the last released asterisk+addons).

I am working with AlexZ to produce a single configuration of * and *-addons where this feature works, and honestly we can't. Trunk in many cases crashes on us one the second call attempt. Alex possibly (though he may have been hallucinating from working on this so hard) got authenticate to work just once.

What version of Bluez are you using? We have some pretty good crashing with some versions of Bluez.

Regards,
tom

Regards,
tom
By: Matthew Nicholson (mnicholson) 2009-04-21 14:30:57

Try the latest trunk version of addons. Several crash bugs were fixed recently there. I have been testing with the latest versions of bluez (4.30, 4.33, 4.34, 4.36).
By: Alexander Zakharov (alexz) 2009-04-21 19:48:57

Ok. My current setup is:
Debian 5 Lenny
Bluez 4.36 (some dancing required in order not to build ipctest, which fails to compile)
OpenVox TDM card with FXS/FXO
Asterisk trunk 189770
Add-ons trunk 878

Problem 1: On both inbound/outbound calls asterisk CLI craps out immediately
Problem 2: On outbound call there is one way audio - called party doesn't hear calling party (everything is OK with stock ast and addons with the same setup above)
Problem 3: On outbound call if calling party hangs then call is not hanging
Problem 4: On outbound call /var/log/asterisk/full is full of the following messages:
[Apr 21 20:22:15] VERBOSE[2922] pbx.c: -- Executing [s@macro-dialout-trunk:26] ^[[1;36
mDial^[[0m("^[[1;35mDAHDI/1-1^[[0m", "^[[1;35mMOBILE/g1/6137978600,300,^[[0m") in new stac
k
[Apr 21 20:22:15] VERBOSE[2922] app_dial.c: -- Called g1/6137978600
[Apr 21 20:22:24] ERROR[2922] res_timing_dahdi.c: Failed to configure DAHDI timing fd for
0 sample timer ticks
[Apr 21 20:22:24] ERROR[2922] res_timing_dahdi.c: Failed to configure DAHDI timing fd for
0 sample timer ticks
[Apr 21 20:22:24] ERROR[2922] res_timing_dahdi.c: Failed to configure DAHDI timing fd for
0 sample timer ticks
..... and so on
AND THERE ARE A LOT OF THEM (17 megs actually)

all problems above are not observed with stock ast/addons

Problem 5: On inbound call sometimes it picks up digits in authenticate (verbal confirmation from ast that password was accepted - can't confirm the same from CLI since it dies), but most of the cases log is FULL (again mega and megs) of

[Apr 21 20:38:57] ERROR[2957] chan_mobile.c: read error 9
[Apr 21 20:38:57] ERROR[2957] chan_mobile.c: read error 9
[Apr 21 20:38:57] ERROR[2957] chan_mobile.c: read error 9
.........

I am completely lost here.

1) Stock ast/addons produce stable outbound call, but no dtmf digits even in background
2) latest rc of ast/addons often produce garbled CLI output, but at least I can see dtmf digits in background
3) Trunk sometimes authenticates, but the rest of functionality is broken

Where it leaves us?

mnicholson - can you please provide us with EXACT ast and addons trunk version that you tested with? We would like to repeat your exact testing (we already abandoned Ubuntu in order to have the same setup as you do)
By: Matthew Nicholson (mnicholson) 2009-04-22 10:14:54

I tested with the same version of addons as you did and asterisk trunk r185846.

(problem 1) If you are experiencing a crash, please open a new bug with a backtrace as described in doc/backtrace.txt.

(problem 2) Please open a new bug for this. Be sure to include details on exactly how to reproduce it.

(problem 3) This is a known bug (issue 0014878)

(problem 4) The timing issues are not related to chan_mobile. Either try using a different timing module or properly set up dahdi to provide timing.

(problem 5) Those read error messages are signs of a bug in the code. Please open a new bug. Be sure to include details on the exact scenario that leads to those messages.
By: Alexander Zakharov (alexz) 2009-04-27 17:23:29

I tested virtually with all the possible permutations of different trunk/release/rc versions of ast and addons, but the only combination that works for us is release, where DTMF is not working (as we know). All of rc/trunk do produce log full of different errors (regardless to the patch/no patch applied in case of rc of addons) including timing. We probably better wait till official release where fix will be submitted, and then will test it again. Too much time spent chasing the ghosts. We do go through the same setup routine (Ubuntu/Debian + LAMP + OpenSSH + Bluez (4.32-4.37) + Release DAHDI + Ast_X + Addons_X + FreePBX) and the only case when we can reliably plece/receive the call is release versions of ast/addons. We tried today exact the same ast r185846 + addons r878 with absolutely the same result as before. Another possible issue is that whole setup procedure that we are using is not valid anymore for trunk/rc versions of Asterisk.

So, our understanding is that fix will be included in the next release of addons 1.6.0 and 1.6.1 - is it correct? WHEN APPROXIMATELY IT WILL HAPPEN?
By: Matthew Nicholson (mnicholson) 2009-04-27 17:30:35

I have not decided if this is going in 1.6.0 and 1.6.1 yet. If I can get all of the bugs worked out, then yes. It is a very invasive change.
By: Francisco Ceballos Peniche (franciscoce) 2009-04-27 22:58:43

This is my configuration:
- Fedora 10 kernel 2.6.27.5-117
- Asterisk trunk r182282
- Asterisk addons program make_version reports SVN-TRUNK-r779M
- bluez 4.17-2
- dongle usb manufacturer: Cambridge Silicon Radio ( CSR )
- cellular GSM motorola v337p and CDMA Motorola K1 (and others)
Notes:
- Delay worked out
- DTMF worked out ( except for first call to chan_mobile with all those phones connected using background app, then it works fine, too )

PLEASE, make sure all bluetooth libraries are installed before compile addons.
Hope this help.
By: Matthew Nicholson (mnicholson) 2009-04-28 11:43:21

@franciscoce

Can you test with the patch from issue ASTERISK-1471878 to see if it fixes the first call issues.
By: Francisco Ceballos Peniche (franciscoce) 2009-04-28 15:43:12

You're right mnicholson, This patch from issue 0014878 solved the "first call background app" problem with asterisk-addons r896. I have no more issues.
Delay and DTMF now works great. For now, the only warning observed is "mbl read: read error 107" message after hangup.
thanks.

By: Alexander Zakharov (alexz) 2009-04-29 16:59:49

@franciscoce

I will try today your setup, except kernel would be 2.6.28 (Ubuntu 9.04)
I think that fundamental difference between our testing is that all of you are using your development/test PC's where you alrea
By: Alexander Zakharov (alexz) 2009-04-29 17:11:40

Sorry, did hit the wrong button... Where was I?

I think that fundamental difference between our testing is that all of you are using your development/test PC's where you already have your "old" setup and just trying new updates. In our case testing is completely new scratch installation:
Ubuntu 9.04 server with LAMP and OpenSSH, minimal system with CLI
Bluez (whatever version we'll choose, from bluez.org - so ALL the libraries and corresponding files are in place)
Dahdi/Tools release (2.1.0.4/2.1.0.2)
Ast (whatever our choice is)
Addons (whatever our choice is)
FreePBX 2.5.1

All the compiling and configuration is done "by book" and verified on many systems.

So far NONE of our scratch installations worked as expected with chan_mobile, except when everything is "release", where as we know DTMF is not working.

We'll make another attempt to do it today - your setup wasn't different from whatever we did already try in a past, except we did use bluez 4.37. We will try 4.17 today, but frankly we do not expect it to be much different. We'll see.
In term of hardware we are using Linksys, Cirago and Trendnet - all CSR chipset based. On a cell phone side all the phones are Nokia (in terms of hardware all the components are the most trusted in terms of bluez and chan_mobile). Machine has TDM400 card from OpenVox with 2 FXO and 2 FXS modules installed.
By: Francisco Ceballos Peniche (franciscoce) 2009-04-29 17:40:58

@alexz
In my configuration all was installed in a brand new partition. No previous setup exists at all.
I used bluez from Fedora and installed bluez-libs later. Can you make outside calls from SVN chan_mobile?
By: Alexander Zakharov (alexz) 2009-04-29 18:19:33

Yes , with yours ast r182282 I can make outbound calls with no problems (later trunk asts (starting one-two weeks ago)do not cooperate nicely with release FreePBX - ast CLI crushes on each attemp of login from FreePBX. I just finished installation of exactly your setup (but Ubuntu 9.04 rather then Fedora, which is 2.6.28 kernel) and turned out that Bluez 4.17 fails to pair with multiple dbus errors (I expect that bluez kernel 2.6.28 modules and bluez4.17 do not live nicely together). There are no deviations in our setups - we do follow exact the same procedure each time. A reason why we would like to stay with kernel 2.6.28 up and bluez 4.32 up is very simple - bluez development community with Marcel Holtman will brush off any questions with regard to earlier releases, not to mention that Marcel personally closed bluez users forum, claiming (and I am not joking here - it's word to word his statement) that "it brings more pain then use" - such a nice statement for community project. So, if you are not bluez developer, then you are on your own. I never saw any of usage related questions (including mine) been answered in bluez developers forum (the only bluez related forum right now). Sad, but it's what we have, unfortunately.
By: Francisco Ceballos Peniche (franciscoce) 2009-04-29 18:48:50

Sounds like audio.diff was not correctly patched all hunks or incorrect paths to libraries or kernel development libraries not installed either.
maybe asterisk-addons config.log helps.
By: BrettS (ughnz) 2009-05-01 04:32:15

Tested the audio patch with:
asterisk 1.6.1.0
addons 1.6.1.0
bluez 3.36
kernel 2.6.18-128.1.6.el5

Audio delay has gone. Still get a few hci_scodata_packet: hci0 SCO packet for unknown connection handle messages in the kernel log.

DISA will still not work. It will either crash asterisk, hang with no dialtone or give dialtone then hang the channel, only a asterisk kill will release the channel.
By: Matthew Nicholson (mnicholson) 2009-05-01 09:31:30

The audio1.diff patch is obsolete. Please test with addons trunk. Those kernel messages are not a chan_mobile bug.
By: Alexander Zakharov (alexz) 2009-05-01 13:30:36

Trunk addons is not compileable with asterisk 1.6.1.0 - something with res_config_mysql.c errors - can we safely remove this resource module?
By: Matthew Nicholson (mnicholson) 2009-05-01 13:37:06

Yes. You can use "make menuselect" to disable that module if you are not using it.
By: BrettS (ughnz) 2009-05-01 20:53:45

Tested with latest trunk of addons. Same setup as before.

1. Needed to re-pair the phone before chan_mobile would connect.
2. Outgoing calls would not work. chan_mobile would dial the number then the phone would switch to normal profile and activate handsfree on the handset. Asterisk would report all channels are busy.
3. Incoming calls on the mobile are ignored. The phone would just ring.
By: Alexander Zakharov (alexz) 2009-05-02 09:08:36

I can confirm ughnz results - on top of his issues we have ast CLI crush on each outgoing call. Before we did testing on embedded platform (ALIX board with AMD Geode processor and Compact Flash). This time we did everything on conventional PC

- conventional PC Intel Quad, 4G RAM
- Ubuntu 9.04 Server with LAMP and OpenSSH (kernel 2.6.28)
- OpenVox PCI TDM400 card with single FXS
- dahdi linux/tools 2.1.0.4 / 2.1.0.2
- Asterisk 1.6.1.0 release
- Addons trunk r899
- FreePBX 2.5.1
- Bluez 4.32 - 4.37 (all exibit the same behaviour)
- Cirago/Lynksys/Trendnet Bluetooth dongles (all CSR based)
- Nokia 2680

Again, everything is OK (except DTMF detection) with 1.6.0 release.

One of the ideas (since looks like I am not paranoic and somebody else sees the same things) - @mnicholson - is it possible for you to post step by step installation instructions from A to Z? May be something changed in setup sequence? This is the only possible thing that left. We can post our installation instructions as well.

Since there are only handful amount of people testing it why don't we joint our forces and nail the difference. There are no miracles in this world - so far two people report no problem and two report exact the same issue - something should be different in some department. Let's share installation procedures for starters - I thing we can start from mnicholson since he is the closest to he shop. Any objections?
By: BrettS (ughnz) 2009-05-02 18:11:31

I agree with alexz, there must be some difference in setup somewhere.

Here is my setup:

- VIA PC-1 system. 1.5GHz CPU with 1G RAM.
- Centos 5.3
- Bluez 3.36
- CSR chipset dongle
- Vodafone 715 mobile
- Asterisk 1.6.1.0 Release
- DAHDI 2.1.0.4

mobile.conf:

;
; mobile.conf
; configuration file for chan_mobile
;

[general]
interval=30 ; Number of seconds between trying to connect to devices.

; The following is a list of adapters we use.
; id must be unique and address is the bdaddr of the adapter from hciconfig.
; Each adapter may only have one device (headset or phone) connected at a time.
; Add an [adapter] entry for each adapter you have.

[adapter]
id=blue
address=xx:xx:xx:xx:xx:xx
;forcemaster=yes
alignmentdetection=yes
;nocallsetup=yes

;[adapter]
;id=blue1
;address=xx:xx:xx:xx:xx:xx
;alignmentdetection=yes

; The following is a list of the devices we deal with.
; Every device listed below will be available for calls in and out of Asterisk.
; Each device needs an adapter=xxxx entry which determines which bluetooth adapter is used.
; Use the CLI command 'mobile search' to discover devices.
; Use the CLI command 'mobile show devices' to see device status.
;
; To place a call out through a mobile phone use Dial(Mobile/[device]/NNN.....) in your dialplan.
; To call a headset use Dial(Mobile/[device]).

[TRUNK]
address=xx:xx:xx:xx:xx:xx ; the address of the phone
port=4 ; the rfcomm port number (from mobile search)
context=from-pstn ; dialplan context for incoming calls
adapter=blue ; adapter to use
dtmfskip=100

;[n95]
;address=xx:xx:xx:xx:xx:xx
;port=3
;context=from-pstn
;adapter=blue1
;dtmfskip=50

hcid.conf:

#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security auto;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device xx:xx:xx:xx:xx:xx {
# Local device name
# %d - device id
# %h - host name
name "trixbox";

# Local device class
class 0x200408;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable; pscan enable;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
#lp rswitch,hold,sniff,park;
}

device xx:xx:xx:xx:xx:xx {
name "trixbox1";
class 0x200408;
iscan enable; pscan enable;
lm accept;
}

hciconfig -a output:

hci0: Type: USB
BD Address: xx:xx:xx:xx:xx:xx ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:384753 acl:376 sco:7232 events:487 errors:0
TX bytes:180438 acl:225 sco:3426 commands:112 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'trixbox'
Class: 0x080408
Service Classes: Capturing
Device Class: Audio/Video, Hands-free
HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver: 0xc5c
Manufacturer: Cambridge Silicon Radio (10)

sdptool browse output:

Service Name: Voice Gateway
Service RecHandle: 0x10000
Service Class ID List:
"Handsfree Audio Gateway" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 4
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Handsfree" (0x111e)
Version: 0x0105

Service Name: A2DP Source
Service RecHandle: 0x10002
Service Class ID List:
"Audio Source" (0x110a)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 25
"AVDTP" (0x0019)
uint16: 0x100
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Advanced Audio" (0x110d)
Version: 0x0100

Service Name: AVRCP Target
Service RecHandle: 0x10003
Service Class ID List:
"AV Remote Target" (0x110c)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 23
"AVCTP" (0x0017)
uint16: 0x100
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"AV Remote" (0x110e)
Version: 0x0100

Service Name: Serial Port
Service RecHandle: 0x10004
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 16
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Serial Port" (0x1101)
Version: 0x0100

Service Name: Information Synchronization
Service RecHandle: 0x10005
Service Class ID List:
"IrMC Sync" (0x1104)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 17
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"IrMC Sync" (0x1104)
Version: 0x0100

Service Name: Object Push
Service RecHandle: 0x10006
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 18
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100

Service Name: File Transfer
Service RecHandle: 0x10007
Service Class ID List:
"OBEX File Transfer" (0x1106)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 19
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"OBEX File Transfer" (0x1106)
Version: 0x0100
By: Matthew Nicholson (mnicholson) 2009-05-04 10:39:05

I am marking this bug as closed. Please open up new bugs for the other issues you are seeing.