bjille / imsdroid

Automatically exported from code.google.com/p/imsdroid
0 stars 0 forks source link

DTMF regression #520

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

1. Checkout IMSDroid Revision 569 from SVN (at the time of this writing this is 
the latest revision available)
2. Build it and run it on an Android device (In this case I've run it on a 
Google Nexus 5 with Android 4.4.2 API 19)
3. Setup a SIP account. In my scenario everything is setup to work in the same 
LAN network, so I don't have NAT or other things involved.
3. Call a number which has an IVR or does different actions based on the DTMF 
tones received from the caller. In my scenario I've called *100 and the I've 
sent 624# as DTMF tones.

What is the expected output? What do you see instead?

The DTMFs sent from the device are not recognized by the SIP server. I expect 
the server to recognize them.

What version of the product are you using? On what operating system?

IMSDroid 2.569.1089 on Google Nexus 5 with Android 4.4.2 (API 19)

Please provide any additional information below.

When I do the same steps described above, but with IMSDroid 2.548.870 on the 
same device, everything works as expected and the DTMF tones are correctly 
detected by the SIP server. I run a freeswitch SIP server setup to work in 
rfc2833 mode. I've done a dump with wireshark. One with IMSDroid 2.569.1089 and 
one with IMSDroid 2.548.870, that you cand find attached to this issue.

Original issue reported on code.google.com by alexgo...@gmail.com on 30 May 2014 at 9:06

Attachments:

GoogleCodeExporter commented 8 years ago
I've done the same steps described above with various versions of IMSDroid.
The first revision which has this issue is 561. 
Everything works correctly until revision 560.

Original comment by alexgo...@gmail.com on 30 May 2014 at 2:08

GoogleCodeExporter commented 8 years ago
I've analyzed the DIFF between rev 560 and rev 561. 
From what I've seen, the problem seems to be with how the doubango library is 
compiled for Android. 
In my opinion, there must be something wrong somewhere between doubango rev 
1026 and doubango rev 1033. Until doubango rev 1025 everything works.

Original comment by alexgo...@gmail.com on 30 May 2014 at 3:01

GoogleCodeExporter commented 8 years ago
From further testing, I've discovered that the problem is related to audio, 
because doubango doesn't play to the user the audio sent from the pbx after 
that the dtmf are recognized. 

Open imsdroid_2.569.1089.pcapng (attached to the first message of this issue) 
with Wireshark and then go to Telephony > VoIP calls.
Select the only one VoIP call detected and then hit on "Player". Click on 
Decode. Check the boxes under each one of the two streams and then click on 
"Play". You can hear a sound, then some silence and then the second sound. The 
issue is that the second sound is not heard from imsdroid.

Original comment by alexgo...@gmail.com on 6 Jun 2014 at 1:21

GoogleCodeExporter commented 8 years ago
"From further testing, I've discovered that the problem is related to audio, 
because doubango doesn't play to the user the audio sent from the pbx after 
that the dtmf are recognized."
?????
Who is supposed to receive DTMF tones? 

Original comment by boss...@yahoo.fr on 6 Jun 2014 at 3:09

GoogleCodeExporter commented 8 years ago
DTMF tones are receiuved by a FreeSWITCH PBX in my case.

TEST ENVIRONMENT THAT I USED
- CentOS 6.5 with the last stable release of FreeSWITCH installed from source 
(Instructions here: http://wiki.freeswitch.org/wiki/Linux_Quick_Install_Guide) 
and firewall shut down. By default there's nothing to configure in freeswitch. 
Everything that we need is in the default configuration.
- Google Nexus 5 with Android 4.4.3 (API 19)
- Android Developer Tools Build: v22.6.2-1085508 on OS X 10.9 (but it's the 
same if you use windows or linux)
- IMSDroid rev 560 (svn checkout 
http://imsdroid.googlecode.com/svn/branches/2.0/@560 imsdroid-560)
- IMSDroid rev 561 (svn checkout 
http://imsdroid.googlecode.com/svn/branches/2.0/@561 imsdroid-561)

PRELIMINARY NOTES
In my setup the freeSWITCH PBX is connected the same LAN on which the phone is 
connected via WiFI. No NAT or other network elements in between.
In my case the freeSWITCH PBX has 192.168.1.203 and my phone has 192.168.1.192
So in the configuration reported below, change the IP accordingly to your 
environment.

HOW TO REPRODUCE
- Build IMSDroid rev 561, install it on your phone
- Configure it like this: 
 - Display name: 1000
 - Public identity: sip:1000@192.168.1.203
 - Private Identity: 1000
 - Password: 1234
 - Realm: sip:192.168.1.203 
 - Proxy-CSCF Host: 192.168.1.203
- Register and call 5000. You'll hear an IVR. Open keypad and press 3. You'll 
hear nothing and after some time the call will be terminated.

Uninstall IMSDroid from your phone, and try the same steps described above, but 
with imsdroid rev 560. You'll hear some music playing after that you press 3. 
This is the desired behaviour.

Original comment by alexgo...@gmail.com on 6 Jun 2014 at 3:12

GoogleCodeExporter commented 8 years ago
You should also ask on freeSWITCH forum because the revisions you're pointing 
don't contain any change related to DTMF.

Original comment by boss...@yahoo.fr on 6 Jun 2014 at 3:17

GoogleCodeExporter commented 8 years ago
No, maybe I'm not expressing the problem well. Initially I thought that the 
problem was caused by erratic DTMF sending, but this is not the issue, because 
after some dumps, I discovered that DTMF are correctly sent from imsdroid and 
received by the pbx server. 

The problem is that imsdroid, starting from revision 561, doesn't play further 
IVR messages after the first one. With the same setup, everything works with 
imsdroid revision 560. Tried also with linphone, zoiper and csipsimple and 
everything works too.

So, it's an audio problem in doubango or a third party library that it's used 
and that has been updated somewhere between revision 1026 and 1033. I've seen 
that there were major third party library updates in doubango revision 1027 
(https://code.google.com/p/doubango/source/detail?r=1027) and doubango revision 
1030 (https://code.google.com/p/doubango/source/detail?r=1030). Maybe the 
problem is there.

Original comment by alexgo...@gmail.com on 6 Jun 2014 at 3:26

GoogleCodeExporter commented 8 years ago
basically, after a DTMF is sent, imsdroid does not play out any further audio 
coming from the softswitch, but the audio is present, as you can see (and 
listen) from the caputer

Original comment by mbrancal...@gmail.com on 6 Jun 2014 at 3:39