search

drneamati / idoubs

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

DTMF tones not send #53

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Make a phone call
2. Try to use the phonepad to send a DTMF tone to the server

What is the expected output? What do you see instead?
The dtmf tone is expected to be send but in the end the server doesn't recieve 
the dtmf tone.

What version of the product or source code revision are you using? On what 
operating system?
iOS 4.3.3 iPhone 4 latest code revisions from both idoubs and doubango

Original issue reported on code.google.com by nightfox...@gmail.com on 15 Jul 2011 at 9:40

GoogleCodeExporter commented 9 years ago 
Very strange because this have been tested several times. There is an open 
thread about DTMF 
(https://groups.google.com/group/doubango/browse_thread/thread/c36164548bc12d41)
 but not the same issue.

Are you using iDoubs v2?

Please not that DTMF digits will only sent when the RTP channel is UP which 
means that you already accepted the call or early media started.

Did you already used wireshark and noticed there is no "rtpevent" packets 
moving from the client?

Original comment by boss...@yahoo.fr on 15 Jul 2011 at 4:01

GoogleCodeExporter commented 9 years ago 
is it applicable when we are making call?

Original comment by palejasu...@gmail.com on 16 Jul 2011 at 7:47

GoogleCodeExporter commented 9 years ago 
Oke after 2,5 hours of extensively testing the SIP server I had to come to the 
conclusion that it is an issue in the Doubango framework. The RTP Event is sent 
to the server but the server doesn't receive anything. 

I've also run whireshark on the SIP server but there is nothing to be found of 
a RTP package that's coming trough. But when I try it with another SIP client 
it works perfectly.

Original comment by nightfox...@gmail.com on 16 Jul 2011 at 9:54

Attachments:

GoogleCodeExporter commented 9 years ago 
"the conclusion that it is an issue in the Doubango framework" => How could it 
be an issue in Doubango if the packet are sent from the client and your server 
doesn't receive anything? I would say it's an issue with your network unless 
you find better explanation. I strictly follow RFC 4733 and already made many 
IOTs.

The "rtpevent" packets use the same RTP channel as the voice so I don't see how 
it could be possible to receive audio bu not dtmf digits.

Original comment by boss...@yahoo.fr on 17 Jul 2011 at 12:33

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I have tried DTMF Test. It is working properly when I am sending single digit, 
Let us say 1. But what I have to do when I want to transfer the call to the 
extesion number let us say 125.

I have tried to send it digit by digit, but call is transferd to first digit 
only, or terminated.
It would be helpful if I will get code for it.

Original comment by palejasu...@gmail.com on 18 Jul 2011 at 10:10

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi Guys,

Great Work..!!

I agree to the Above.. 

DTMF works but only for Singal Digit. 

E.g for an IVR where pressing Single Digit is required It works fine.
But When Multiple Digit e.g. 12,2333,etc.. is required the call gets 
terminated. 

The same issue is found IMSDROID & IDOUBS.

I am using Asterisk as my Testing Server& I have used X-Lite Phone as a SIP 
client  check the server conf & it works fine. I guess then their no problem 
with Server & RTP.

Best of luck..!!

Original comment by narij...@gmail.com on 18 Jul 2011 at 12:14

GoogleCodeExporter commented 9 years ago 
To all:
I have already said it and I'll say it again: All is correct with our 
implementation and please check that the "rtpevent" packets send from Doubango 
are not too short (duration) or long for your server. Most of open source 
servers have it "hard coded".
Please don't say something like: "I have tested with xxx client and it's 
working so the problem comes from iDoubs/IMSDroid/Boghe...."
If you found that there is a problem on our implementation (RFC 4733) please 
point it and we will make the changes.
There is an discussion about DTMF issue here: 
https://groups.google.com/group/doubango/browse_thread/thread/c36164548bc12d41

@narij...@gmail.com

It's not because it's working with x-lite that there is no problem on your 
server.

Original comment by boss...@yahoo.fr on 18 Jul 2011 at 4:28

GoogleCodeExporter commented 9 years ago 
Mamadou,

You owe me a sincere apology! :-)

After all we have discovered that the issue was the dtmfmode on the server 
which was inband mode. After changing it to the rfc2833 mode it worked 
perfectly.

I've never said anything :-#

Thanks for the feed back.

Original comment by nightfox...@gmail.com on 19 Jul 2011 at 10:01

GoogleCodeExporter commented 9 years ago 
Hi Mamadou,

My Heartly apologies....!!
I had no intentions of showing or coming to a conclusion that it not works or 
it works with Application X & not with iDoubs & IMSDroid so it has a bugs.. I 
had no intentions of that.. Once again sorry for putting my concern in a wrong 
frame of words..All i wanted is to mention that I had tested it with a 
softphone and basic configuration..!!
After doing some Wireshark & other Research.. I Found out that am getting DTMF 
three time.. ... e.g. if I am sending “1” I am getting “111” on my 
server.. if i m pressing “23” I am getting “222333” so its sending each 
digit three times.. 
Initially i thought it might be some issues with my Server so I re-installed 
FreePBX but still getting the it three times.....  

Once again Thanks for Giving us a awesome Framework & Application ... along 
with a Promt support...

Regards

Original comment by narij...@gmail.com on 19 Jul 2011 at 2:13

GoogleCodeExporter commented 9 years ago 
@narij...@gmail.com
Sorry for the rude response.

The retransmission is correct according to RFC 4733. For example, when you 
press "2" you will have:
"2" -> Start
"2"
"2"
"2"
"2" -> End
"2" -> End

The retransmission is used to deal with packet lost or simulate "long press". 
The retransmission is totally detectable because of the "Start" and "End". All 
servers I've seen correctly handle this basic scenario. Are you developing your 
own server?

Original comment by boss...@yahoo.fr on 20 Jul 2011 at 2:25

GoogleCodeExporter commented 9 years ago 
Hi Mamadou, 

Thanks for your reply.... & it’s absolutely fine I understand one can get 
irritated by this kind of comments from a beginner like me for hard worked 
project and trust me after seeing all your hard-work for development & 
Support.. you should..!! ...Hope the misunderstanding is cleared..!!!

I am using a Asterisk 1.6.2.6... After Reading your comments I went through the 
RTP debug on Asterisk server. Please find attached the RTP for RFC2388 I 
received from Idoubs & X-Lite... there is some difference the way it comes to 
the server. It would be great if you can guide what I am missing in my settings.

Regards..!!

Original comment by narij...@gmail.com on 20 Jul 2011 at 1:26

Attachments:

GoogleCodeExporter commented 9 years ago 
What are the settings in the config file on your server? And does the server 
recieve any of the packages at all?

What fixed the problem for me was to use one codec for example PCMA and set the 
correct configuration on the server for PCMA dtmfmode (look for it on google) 
there it'll be explained what type of dtmfmode you'll need to use.

Original comment by nightfox...@gmail.com on 21 Jul 2011 at 1:28

GoogleCodeExporter commented 9 years ago 
Hi Guys,

@nightfox..

Thanks for your advice.. I googled arround to tweak settings in Asterisk.. and 
it worked..

All i did is  commented Following line in sip.conf of asterisk

dtmfrelax=yes

@Mamadou

Thanks for the help .. and no Hard Feelings. Once again thanks for amazing 
stuff..

Cheers..!!

Original comment by narij...@gmail.com on 29 Jul 2011 at 9:51

GoogleCodeExporter commented 9 years ago

Original comment by boss...@yahoo.fr on 8 Jun 2012 at 11:28