diff options
author | Richard Mudgett <rmudgett@digium.com> | 2010-11-24 22:52:07 +0000 |
---|---|---|
committer | Richard Mudgett <rmudgett@digium.com> | 2010-11-24 22:52:07 +0000 |
commit | ccdc417ab57102d11d055dbaec943bf6adfdd337 (patch) | |
tree | 22b95a7e3536d461b8b29dd4af3fbdb6b0f5ddde /channels/sig_pri.h | |
parent | ddd0ae53d23f432a16e01a603120d8ff97ea53a4 (diff) |
Merged revisions 296167 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296167 | rmudgett | 2010-11-24 16:49:48 -0600 (Wed, 24 Nov 2010) | 57 lines
Merged revisions 296166 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296166 | rmudgett | 2010-11-24 16:42:45 -0600 (Wed, 24 Nov 2010) | 50 lines
Merged revisions 296165 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296165 | rmudgett | 2010-11-24 16:41:07 -0600 (Wed, 24 Nov 2010) | 43 lines
Oneway audio to SIP phone from FXS port after FXS port gets a CallWaiting pip.
The FXS connected phone has to have CW/CID support to fail, as it will
send back a DTMF 'A' or 'D' when it's ready to receive CallerID. A normal
phone with no CID never fails. Also the SIP phone does not hear MOH when
the CW call is answered.
The DTMF end frame is suppressed when the phone acknowledges the CW signal
for CID. The problem is the DTMF begin frame needs to be suppressed as
well. The DTMF begin frame is causing SIP to start sending the DTMF RTP
frames. Since the DTMF end frame is suppressed, SIP will not stop sending
those DTMF RTP packets.
* Suppress the DTMF begin and end frames when the channel driver is
looking for DTMF digits.
* Fixed a couple issues caused by not cleaning up the CID spill if you
answer the CW call while it is sending the CID spill.
* Fixed not sending CW/CID spill to the phone when the call is natively
bridged. (Fixed by not using native bridge if CW/CID is possible.)
* Suppress received audio when sending CW/CID spills. The other parties
involved do not need to hear the CW/CID spills and may be confused if the
CW call is for them.
(closes issue #18129)
Reported by: alecdavis
Patches:
issue_18129_v1.8_v3.patch uploaded by rmudgett (license 664)
Tested by: alecdavis, rmudgett
NOTE:
* v1.4 does not have the main problem fixed by suppressing the DTMF start
frames. The other three items fixed are relevant.
* If you really must restore native bridging between analog ports, you
need to disable CW/CID either by configuring chan_dahdi.conf
callwaitingcallerid=no or dialing *70 before dialing the number to
temporarily disable CW.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'channels/sig_pri.h')
-rw-r--r-- | channels/sig_pri.h | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/channels/sig_pri.h b/channels/sig_pri.h index 06dad4ea7..8f2ee20e4 100644 --- a/channels/sig_pri.h +++ b/channels/sig_pri.h @@ -90,10 +90,10 @@ struct sig_pri_callback { void (* const unlock_private)(void *pvt); /* Lock the private in the signalling private structure. ... */ void (* const lock_private)(void *pvt); - /* Function which is called back to handle any other DTMF up events that are received. Called by analog_handle_event. Why is this + /* Function which is called back to handle any other DTMF events that are received. Called by analog_handle_event. Why is this * important to use, instead of just directly using events received before they are passed into the library? Because sometimes, * (CWCID) the library absorbs DTMF events received. */ - //void (* const handle_dtmfup)(void *pvt, struct ast_channel *ast, enum analog_sub analog_index, struct ast_frame **dest); + //void (* const handle_dtmf)(void *pvt, struct ast_channel *ast, enum analog_sub analog_index, struct ast_frame **dest); //int (* const dial_digits)(void *pvt, enum analog_sub sub, struct analog_dialoperation *dop); int (* const play_tone)(void *pvt, enum sig_pri_tone tone); |