Closed GoogleCodeExporter closed 9 years ago
Original comment by dc3de...@gmail.com
on 11 Aug 2010 at 6:39
See r195 - Refactored dialing feedback (tone and haptic) into new class
utils/DialingFeedback.java. This is called from both Dialer and InCallActivity.
I think I was correct in not calling setVolumeControlStream on the
STREAM_VOICE_CALL in the InCallActivity.
Original comment by dc3de...@gmail.com
on 11 Aug 2010 at 6:47
Sounds good.
Yes your right, while in call, stream volume control should be managed by
inCall activity.
Besides one important thing you may not noticed is that the inCall dialer send
DTMF sounds using the pjsip library. So while in call, not needed to give audio
feedback (and it can become really unstable to add audio on the top of the
pjsip streams)
So what I advise that if boolean inCall is true in DialingFeedback to set
dialPressTone to false : we must make sure that DTMF is only sent by pjsip
stack.
(Testing that vibrator doesn't produce sound that is mixed with DTMF sent by
pjsip could be great too... else let me know, I can remove the conference port
from the micro while dialing a DTMF char).
Original comment by r3gis...@gmail.com
on 11 Aug 2010 at 7:15
Well, without the TOneGenerator sounds, I hear nothing when I press the in-call
dialpad. I did see that it is sending DTMF via pjsip stack. However, that DTMF
is inaudible by the local user. I use the ToneGenerator now to play DTMF
through the earpiece/speaker/BT. I don't think it is going out to the
remote/callee. I listened at the other end and heard the same thing (clean
DTMF) whether I have tone feedback enabled or not. So I conclude that the tone
feedback is not actually going over the connection to the other end, it is only
being played at the local end. Again, without that, I hear nothing when
pressing the in-call dialpad buttons.
The vibrator does not produce any sound that can be heard by the remote end, so
this is OK also.
Original comment by dc3de...@gmail.com
on 11 Aug 2010 at 8:00
Oh, yes sorry you're absolutely right. All the more so as output audio is not
mixed with micro input (excepted on the Sony X10... :/ )
Well should be ok. There is just a little fear about sound mixing on device on
which there is already issues, but actually not due to this improvement.
Original comment by r3gis...@gmail.com
on 11 Aug 2010 at 8:50
See r196 - Tone/haptic pref changes not seen until program restart. Fixed this.
Original comment by dc3de...@gmail.com
on 11 Aug 2010 at 11:02
Just a note: there are three ways to indicate numeric buttons presses in SIP:
RFC2833 (RTP Payload for DTMF Digits...), RFC2976 (SIP INFO method) and
"inline". Only the last one involves real DTMF sound signal being encoded with
the current codec and sent over the RTP audio stream. I think that is rarely
used these days. The other two send the button press events in as either
special (not audio) RTP payload or as a SIP message.
Original comment by egcros...@gmail.com
on 14 Aug 2010 at 9:46
Sending dtmf using the audio stream is the more compatible way.
Many sip providers that does pstn gateway doesnt provide support for RFC2833 or
RFC2976.
But, pjsip support both this features (see :
http://trac.pjsip.org/repos/wiki/FAQ#dtmf). Well it's not yet implemented since
inline sending is in most case enough to dial dtmf codes. So we can imagine
in the future to support both method described in rfc2833 and 2976 but for now
that's not really necessary.
Original comment by r3gis...@gmail.com
on 14 Aug 2010 at 12:41
Original issue reported on code.google.com by
dc3de...@gmail.com
on 11 Aug 2010 at 2:49