ASTERISK-16803: [patch] Oneway audio from SIP phone to FXS port after FXS port gets a CallWaiting pip

[Home]

Summary: ASTERISK-16803: [patch] Oneway audio from SIP phone to FXS port after FXS port gets a CallWaiting pip

Reporter: Alec Davis (alecdavis) Labels:

Date Opened: 2010-10-13 04:31:47 Date Closed: 2011-01-09 22:01:53.000-0600

Priority: Minor Regression? No

Status: Closed/Complete Components: Channels/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) bug18129.diff.txt
( 1) bug18129.diff2.txt
( 2) bug18129.diff3.txt
( 3) callwait-nomoh.txt
( 4) full-18129.txt
( 5) issue_18129_v1.8_v2.patch
( 6) issue_18129_v1.8_v2.tweak.patch
( 7) issue_18129_v1.8_v3.patch
( 8) issue_18129_v1.8.patch

Description: Internal SIP phone initiates a call with FXS port on TDM800P.
FXS connected phone has to have FSK CIDCW 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.

External call comes in on FXO port, and attempts to ring FXS ports.
Call waiting beep is heard at FXS port, also no outbound audio to SIP phone.

Then FXS port hook flashes, the FXO port is then connected to FXS as expected.
But SIP device should hear MOH, but has dead air.

If the FXS port hook flashes to the SIP device, the FXO call then does hear MOH.
Hook flash again back to FXO call, SIP hears nothing.

****** ADDITIONAL INFORMATION ******

In a second senario, start the same as above.
SIP phone initiates a call with FXS port, which is answered.

If FXS port hook flashes to make another call, SIP hears MOH.

But unrelated - the FXS port at this stage is not able to hook flash between calls, which would have tested the MOH swapping between calls.

Comments: By: Alec Davis (alecdavis) 2010-10-13 04:54:22

callwait-nomoh.txt: console output capture and annotated
full-18129.txt: corressponding full file log for the same call

By: Alec Davis (alecdavis) 2010-10-14 05:43:11

Another related issue, is one way audio from first caller, as soon as the call waiting beep starts.

Can be corrected by 'B' pressing DTMF key!!!!! But not by 'A' pressing a key.

SIP 'A' --call 1--->>---------[ASTERISK]---->>----'B' FXS port
SIP 'C' --call 2--->>---------+

'A' calls 'B', 'B' answers, all ok so far
'C' calls 'B', 'B' hears beep
A<-B audio is dead!
A->B audio OK
'B' presses a DTMF key
A<->B audio now OK

'B' now hook flashes to answer 'C'
'A' has MOH
C<->B audio OK

'B' now hook flashes to 'A'
'C' has MOH
A<->B audio OK.
By: Alec Davis (alecdavis) 2010-10-14 13:43:37

Thrid senario works.

External call FXO <-> FXS port established.

2nd call SIP -> FXS port.
CW beep heard at FXS port.

FXS port can hook flash to answer SIP call.
FXO port has MOH as expected.
By: Alec Davis (alecdavis) 2010-10-19 05:08:00

Uploaded bug18129.diff.txt

The issue is as the callwaiting spill to sent to the FXS port, the DSP is triggers on a DTMF.

Then the RTP engine sends DTMF packets continuously to the SIP device, hence the continuous tone.

This patch disabled the DTMF detection, when the callwait is started.

This can be simulated by
establish a call from FXS port -> SIP phone
then from CLI
console dial 89@phones
By: Alec Davis (alecdavis) 2010-10-19 05:19:50

Problem repeatable with:

SVN-trunk-r291658M
SVN-branch-1.6.2-r292229M
By: Alec Davis (alecdavis) 2010-10-19 05:25:18

1.6.2 Without patch: Example console output: with rtp debug on

Got RTP packet from 192.168.124.250:35010 (type 00, seq 001895, ts 3309220, len 000160)
Sent RTP packet to 192.168.124.250:35010 (type 00, seq 043324, ts 080480, len 000160)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001896, ts 3309380, len 000160)
Sent RTP packet to 192.168.124.250:35010 (type 00, seq 043325, ts 080640, len 000160)
asterix*CLI> console dial 89@phones
[2010-10-19 23:21:47.024338] WARNING[21102]: chan_oss.c:486 setformat: Unable to re-open DSP device /dev/dsp: No such file or directory
[2010-10-19 23:21:47.024949] NOTICE[21102]: console_video.c:133 console_video_start: voice only, console video support not present
-- Executing [89@phones:1] Dial("Console/dsp", "DAHDI/35,60") in new stack
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001897, ts 3309540, len 000160)
-- Called 35
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001898, ts 3309700, len 000160)
-- DAHDI/35-2 is ringing
Sent RTP packet to 192.168.124.250:35010 (type 00, seq 043326, ts 080800, len 000160)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001899, ts 3309860, len 000160)
...
Sent RTP packet to 192.168.124.250:35010 (type 00, seq 043347, ts 084160, len 000160)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001920, ts 3313220, len 000160)
Sent RTP packet to 192.168.124.250:35010 (type 00, seq 043348, ts 084320, len 000160)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001921, ts 3313380, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043349, ts 084480, len 000004)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043350, ts 084480, len 000004)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043351, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001922, ts 3313540, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043352, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001923, ts 3313700, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043353, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001924, ts 3313860, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043354, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001925, ts 3314020, len 000160)
-- CPE supports Call Waiting Caller*ID. Sending '/'
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043355, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001926, ts 3314180, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043356, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001927, ts 3314340, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043357, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001928, ts 3314500, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043358, ts 084480, len 000004)
Got RTP packet from 192.168.124.250:35010 (type 00, seq 001929, ts 3314660, len 000160)
Sent RTP DTMF packet to 192.168.124.250:35010 (type 101, seq 043359, ts 084480, len 000004)

By: Alec Davis (alecdavis) 2010-10-19 06:37:03

uploaded diff2.txt
previous version didn't re-enable DTMF detection after CW spill had finished.
By: Alec Davis (alecdavis) 2010-10-20 02:42:00

Main description updated: Requires an analog handset with CIDCW support.

in chan_dahdi.conf the 'callwaitingcallerid' default is yes
; Support caller ID on Call Waiting
;
callwaitingcallerid=yes

Setting 'callwaitingcallerid=no' avoids the current problem.

Disabling the DTMF detector was the wrong approach, SAS+CAS signalling requires the DTMF detector to monitor for a CPE response of DTMF 'A' or 'D', which is acknowledgement to start sending the CallerID spill.

Seems like;
All parties hear part of the SAS (440Hz tone) - varies.
All parties in existing conference should be muted from the Called phone for 500ms while the SAS+CAS signalling is going on.

Proceedure should be: Seems like steps 1 and 7 are missing.

1. Mute other parties, timeout 500ms (unmute on timeout).
2. Send SAS: Subscriber alert Signal of 440Hz
3. ~50ms delay
4. Send CAS: CPE alert Signal CAS tone 1 (2130 Hz) and CAS tone 2 (2750 Hz) to get the CPE’s attention.
5. Wait for CPE to send an acknowledgement (DTMF 'A' or DTMF 'D').
6. If ack received send CallerID FSK spill.
7. Unmute other parties.

During Step 5 above (when the CPE reponds), is when the RTP DTMF stream is then continously sent to the other parties in the 1st call.

By: Alec Davis (alecdavis) 2010-11-04 03:00:29

<<<<<<<<<BT100 in conversation with FXS port>>>>>>>>>>
<<LAPTOP dials FXS PORT>>
== Using SIP RTP CoS mark 5
-- Executing [89@phones:1] Dial("SIP/laptop-00000002", "DAHDI/35,60") in new stack
[2010-11-04 20:44:25.647975] NOTICE[20179]: chan_dahdi.c:5038 save_conference: Disabled conferencing
[2010-11-04 20:44:25.648056] WARNING[20179]: chan_dahdi.c:1876 my_callwait: CIDCW + CAS
-- Called 35
-- DAHDI/35-2 is ringing
[2010-11-04 20:44:26.127122] NOTICE[20178]: chan_sip.c:6225 sip_senddigit_begin: SIP_DTMF_RFC2833 SIP/bt100black-00000001 digit=D
<<BT100 has heard beginning of FXS phone's ACK response to the CAS (a DTMF 'D') and is now begin sent DTMF RTP packets>>
[2010-11-04 20:44:26.207062] NOTICE[20178]: sig_analog.c:1576 analog_handle_dtmfup: Got some DTMF, but it's for the CAS
[2010-11-04 20:44:26.726994] NOTICE[20178]: chan_dahdi.c:5054 restore_conference: Restored conferencing
[2010-11-04 20:44:35.627104] NOTICE[20178]: chan_dahdi.c:5038 save_conference: Disabled conferencing
[2010-11-04 20:44:35.627187] WARNING[20178]: chan_dahdi.c:5155 dahdi_callwait: CIDCW no CAS
<<Hangup 2nd call>>
-- Hanging up on 'DAHDI/35-2'
-- Hungup 'DAHDI/35-2'
== Spawn extension (phones, 89, 1) exited non-zero on 'SIP/laptop-00000002'
<<FXS port about to dial '1' to restore voice with BT100>>
[2010-11-04 20:44:51.407313] NOTICE[20178]: chan_sip.c:6225 sip_senddigit_begin: SIP_DTMF_RFC2833 SIP/bt100black-00000001 digit=1
[2010-11-04 20:44:51.527518] NOTICE[20178]: chan_sip.c:6251 sip_senddigit_end: SIP_DTMF_RFC2833 SIP/bt100black-00000001 digit=1

The previous approach to disable the DTMF detector, seems like it should be disabled for all other parties, except for the FXS port which is being called.

By: Alec Davis (alecdavis) 2010-11-04 03:25:01

There actually are 2 problems here.

1. The DSP DTMF detector doesn't send an DTMF end event, even though it's sent a DTMF begin event.

2. To avoid 1 above, avoidance code needs to mute the other channels that are not involved in the SAS+CAS signalling.
By: Alec Davis (alecdavis) 2010-11-04 06:23:03

uploaded bug18129.diff3.txt

Now mutes conference during SAS+CAS signalling.
By: Richard Mudgett (rmudgett) 2010-11-18 12:31:21.000-0600

The changes done in trunk revisions -r293531 and -r293808 may help although they were mainly directed at three way calling.
By: Alec Davis (alecdavis) 2010-11-18 13:01:02.000-0600

Hopefully can check later today/night.

I've been mulling this over, and my statement to mute the other party/parties is wrong, as in the case of many in a meetme conference.
The received voice/data/dtmf from the device being rung at the FXS port should not be forwarded (bridged) to the conference during SAS+CAS signalling.
By: Richard Mudgett (rmudgett) 2010-11-18 14:08:32.000-0600

I can reproduce. The dahdi_handle_dtmfup() and analog_handle_dtmfup() calls replace the DTMF end control frame with something else. They need to be modified to replace the DTMF begin frame with a NULL frame as well.
By: Alec Davis (alecdavis) 2010-11-22 14:36:15.000-0600

richard: I see some oneway patches applied relating to sig_anlog not being in sync. Did they fix this issue?

I noted that you could reproduce, so didn't test - sorry If I should have done.
By: Richard Mudgett (rmudgett) 2010-11-22 14:50:46.000-0600

No. The one-way patch fixed another CW/CID issue as described by the commit message.

The issue you found is possible on 1.4 and later. 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/replaced, SIP never stops sending those DTMF RTP packets.

I have a patch just about ready for testing once I resolve a related CW/CID issue I discovered.
By: Alec Davis (alecdavis) 2010-11-22 15:11:31.000-0600

umm, try to fix one bug, find 3 others....
By: Richard Mudgett (rmudgett) 2010-11-22 16:39:29.000-0600

The issue_18129_v1.8.patch fixes this issue. It suppresses the DTMF begin frame as well as the DTMF end frame. It also fixes a couple cleanup issues if you answer the call while it is doing the CID spill.

The new problem I found is the CW/CID spill is not sent if the call is natively bridged to another analog port. The analog port does not detect the CW CAS DTMF 'D' response from the phone so the CID spill is not sent. DTMF detection is disabled when in a native bridge. To fix the native bridge issue is going to need more thought. Simply enabling DTMF detection results in doubled digits.
By: Richard Mudgett (rmudgett) 2010-11-22 17:27:33.000-0600

The issue_18129_v1.8_v2.patch fixes the CW/CID spill problem described in 0129064. I found a comment in dahdi_bridge() about native bridging not supporting DTMF detection due to unresolved issues.
By: Alec Davis (alecdavis) 2010-11-23 01:06:23.000-0600

succesfully applied patch issue_18129_v1.8_v2.patch to SVN-trunk-r295870M

Before patch confirmed oneway audio was still a problem with SVN-trunk-r295870M.
After patch, confirmed existing problem was fixed, and correct CWCID sent to the FXS port.

Test setup:
Call 1: SIPA (grandstream) -> FXS port 1, answered and talking
Call 2: SIPB (xlite) -> FXS port 1, callwait pip, FSK and further CW pips.

Another related issue, now that CWCID is working :D, using the above test senario, is that the SIPA Caller hears the initial CW pip and the CW-CID as it's being sent to the FXS connected phone, the successive CW pips are muted for the intial SIPA caller.

This is where I believe the FXS port being called needs to be isolated somehow during the initial CWCID exchange, like is done for the succesive CW pips.

The reason this is an issue, is that neither party knows if it's them that has a call waiting.

I wonder (untested), if the initial call was between 2 analog FXS ports, would they both get the CW-CID of the 2nd caller?

By: Alec Davis (alecdavis) 2010-11-23 03:28:05.000-0600

issue_18129_v1.8_v2.tweak.patch

Noticed possible out by 1 sample.
If ever possible, if 1 sample was set for 'cidcwexpire' the restore_conference isn't in the code path.

now follows/similar to
if (p->ringt > 0) {
if (!(--p->ringt)) {
By: Richard Mudgett (rmudgett) 2010-11-23 16:26:34.000-0600

The issue_18129_v1.8_v3.patch incorporates your issue_18129_v1.8_v2.tweak.patch and also fixes the other parties hearing the CW/CID spills.
By: Alec Davis (alecdavis) 2010-11-24 01:11:40.000-0600

Succesfully applied issue_18129_v1.8_v3.patch.

Same simple tests as before in ~129068, worked as expected.

Also tested and worked.
call1, FXO port 1 -> FXS port 1, established and talking.
call2, SIP -> FXS port1 , muted at FXO port, callwaiting pip at FXS, then CW spill at FXS, unmuted at FXO.

I'm happy.
By: Alec Davis (alecdavis) 2010-11-24 01:55:07.000-0600

unrelated? But as this all works well now, you should be able to choose whether to answer the 2nd caller.

Using my test senario from ~129068 when SIPA hangs up first from call1 with FXS port, SIPB on call-waiting is automatically connected to the FXS port! Yuck - you might not want to answer the call-waiting call, guess it saves a hook flash.

By: Richard Mudgett (rmudgett) 2010-11-24 09:25:07.000-0600

I saw that auto-connect to the CW call as well. There is some code to wait for the called party to explicitly answer the CW call. Apparently it does not work under all conditions. Anyway that is another issue.

I will work on committing the fix to the various branches today.
By: Alec Davis (alecdavis) 2010-11-24 12:55:15.000-0600

Now for some post analysis.

Have these issues always been a problem? Every asterisk based analog FXS gateway may benefit from these fixes, as when first deployed with basic phones it worked, then as the site upgraded their phones with CWCID capable phones, these issues started to pop up.

Especially as 'callwaitingcallerid=yes' is the default.

The above senario is what happened here, seemed to work fine initially, then got a new phone, and thats when the 'fun' started.

Good work, expect to see a ramp up in FXS port sales.
By: Richard Mudgett (rmudgett) 2010-11-24 13:14:18.000-0600

CW/CID likely broke when the DTMF begin/end events were added to Asterisk. There used to be just a DTMF event sent when the DTMF signal ended.
By: Digium Subversion (svnbot) 2010-11-24 16:41:08.000-0600

Repository: asterisk
Revision: 296165

U branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r296165 | rmudgett | 2010-11-24 16:41:08 -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 ASTERISK-16803)
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.

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=296165
By: Digium Subversion (svnbot) 2010-11-24 16:42:47.000-0600

Repository: asterisk
Revision: 296166

_U branches/1.6.2/
U branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r296166 | rmudgett | 2010-11-24 16:42:46 -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 ASTERISK-16803)
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.
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=296166
By: Digium Subversion (svnbot) 2010-11-24 16:49:49.000-0600

Repository: asterisk
Revision: 296167

_U branches/1.8/
U branches/1.8/channels/chan_dahdi.c
U branches/1.8/channels/sig_analog.c
U branches/1.8/channels/sig_analog.h
U branches/1.8/channels/sig_pri.h

------------------------------------------------------------------------
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 ASTERISK-16803)
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.
........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=296167
By: Digium Subversion (svnbot) 2010-11-24 16:52:08.000-0600

Repository: asterisk
Revision: 296168

_U trunk/
U trunk/channels/chan_dahdi.c
U trunk/channels/sig_analog.c
U trunk/channels/sig_analog.h
U trunk/channels/sig_pri.h

------------------------------------------------------------------------
r296168 | rmudgett | 2010-11-24 16:52:08 -0600 (Wed, 24 Nov 2010) | 64 lines

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 ASTERISK-16803)
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.
........
................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=296168