[Home]

Summary:ASTERISK-02750: [patch] Do not use call progress analysis on PRI links
Reporter:Paul Cadach (pcadach)Labels:
Date Opened:2004-11-06 12:17:41.000-0600Date Closed:2008-01-15 15:22:47.000-0600
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) analogphone.log
( 1) modemserver.log
( 2) phoneserv.log
( 3) region.log
( 4) zap_pri_callprogress.diff
( 5) zap_pri_callprogress.diff
( 6) zap_pri_callprogress.diff
Description:Misconfiguration of callprogress field at zapata.conf causes answering of PRI links. Due to "intellect" of PRI signalling inband call progress analysis isn't required. This patch forces "callprogress=no" if signalling is PRI.

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

Disclaimer is on the file.

This bug is reported by xpasha.
Comments:By: Mark Spencer (markster) 2004-11-06 12:19:45.000-0600

Actually we *do* want to do call progress on PRI in order to determine Special Information Tone (SIT) and in-band busy etc. if the user elects.
By: Paul Cadach (pcadach) 2004-11-06 14:19:03.000-0600

Updated patch is available. Call progress analysis is enabled after PROGRESS message is received only.

edited on: 11-06-04 14:58
By: Mark Spencer (markster) 2004-11-06 19:18:47.000-0600

Why only if PROGRESS is received?
By: Paul Cadach (pcadach) 2004-11-06 23:14:51.000-0600

This is main difference and preference of ISDN/SS7 signalling comparing to other older ones. When connection goes out from ISDN/SS7 (i.e. where no digital signalling is available), network must provide PROGRESS message with progress IE=8 (In-band info is available), so this is only one case to analyse call progress tones. When connection is true ISDN/SS7, call progress will be available through ALERTING/CONNECT/DISCONNECT messages...

Also, as I know R1.5 (exUSSR CAS signalling) and R2 signallings, there messages like ANSWER, remote BUSY, CONGESTION, NO ANSWER, DISCONNECT is available, so call progress analysis is not required for such connections too (of course if someone/something is not violates existing specifications).

I attached sample call traces to our phone number service (phoneserv.log ISDN from me, SS7 over network and CAS to call distribution hardware), to region (region.log ISDN then SS7 then R1.5) and to modem server connected to network with R2 (modemserv.log). As you can see, R2 isn't uses PROGRESS message because R2 have all messages required to provide call state information without analysing in-band tones.
By: Paul Cadach (pcadach) 2004-11-06 23:34:12.000-0600

Also, calls to analog phones connected directly to ISDN/SS7 capable switches (i.e. which is able to provide correct information about calling line status) isn't sends PROGRESS message (see analogphone.log).

To summary, call progress analysis is required when and only when interworking is exists and a call is not end-to-end ISDN, but network provides PROGRESS message with indication of such cases, so PROGRESS is the best and single place to enable call progress analysis at Asterisk side.


PS: If the US networks works differently (but I'm not sure abour) support could be provided if call dumps is available.

PPS: Usage of progress indicator for deducing where inband analysis is required is not possible because PI=8 provided everytime when call is not clear ISDN-to-ISDN (for example, remote end connected to analog subscriber line, but switch itself have true ISDN/SS7 connection to the network and is able to provide remote end state correctly within outband signalling).
By: Mark Spencer (markster) 2004-11-07 11:14:14.000-0600

But you can receive a progress indicator in several messages including ALERTING, CALL PROCEEDING, CONNECT, DISCONNECT, PROGRESS, SETUP and SETUP ACKNOWLEDGE.

While it's probably not relevant for DISCONNECT or CONNECT it's still probably important for the others.
By: Mark Spencer (markster) 2004-11-16 18:09:38.000-0600

Where do we stand with this?
By: Paul Cadach (pcadach) 2004-11-17 12:31:53.000-0600

Patch is updated to handle PIs at all messages where progress field is available. Also it have support for new progressmask field (see ASTERISK-2773).
By: Kevin P. Fleming (kpfleming) 2004-12-11 23:13:28.000-0600

With this patch in place on recent CVS (from yesterday, approximately), I don't receive incoming DTMF indication from PRI callers. They cannot nagivate IVR menus, voicemail, or anything else.

Reverting this patch (only) restores DTMF input and things work as expected.
By: Clod Patry (junky) 2004-12-21 00:07:49.000-0600

kpfleming: with Corydon's patch (zap_pri_callprogress.diff), do you have the same behavior as you had as you reported the 12-11-04 23:13?
By: Kevin P. Fleming (kpfleming) 2004-12-21 00:12:18.000-0600

That was the patch I tested. When I first came across this bug, the previous patches had already been removed, leaving only the one from 11-17-04.
By: Kevin P. Fleming (kpfleming) 2004-12-21 00:16:20.000-0600

Actually, now that I look over the patch again, I can see why it's failing: incoming calls on a PRI always use "inband" DTMF, the PSTN switches don't make any effort to analyze the audio stream and pick out the DTMF.

That means Zaptel's DSP code must always be turned on to pick up the incoming DTMF, and with this patch, if a call never gets PROGRESS from the PSTN, the DSP code will never be enabled for the life of that call.

I believe the patch should be modified to turn on DSP if either PROGRESS is received _or_ the call is answered (at least based on my limited understanding of Zaptel).
By: Kevin P. Fleming (kpfleming) 2004-12-21 08:41:05.000-0600

OK, I was up way too late last night... my previous comments are completely off-target.

This patch is supposed to only affect _outgoing_ calls on the PRI links, but the effect I saw was on an _incoming_ call.

So, I believe the patch should do the following:

- on incoming calls, no change

- on outgoing calls, leave DSP turned off until either PROGRESS is received or the call is answered
By: petersv (petersv) 2004-12-21 09:08:56.000-0600

There is code in chan_zap.c to ignore dtmf tones on a pri span when it is set to overlap dialing. With your (kpfleming's) proposed patch I guess that code would not be needed.
By: Paul Cadach (pcadach) 2004-12-21 11:13:21.000-0600

petersv: I'll try to update this patch for current CVS ASAP (I'm pretty busy now :( ). This patch is designed to disable call progress analysis (not DTMF!) until we receive some sort of PRI message with Progress Indicator field set to 8 (in-band or appropriate information is available).
By: Paul Cadach (pcadach) 2004-12-21 11:33:01.000-0600

Ok, I found place of my mistake. It is on patch block @@ -4528,6 +4529,15 @@ - feature is reset to zero independedly on channel direction (incoming or outgoing). I'll try to fix that when will prepare new patch for current CVS.
By: Paul Cadach (pcadach) 2004-12-21 12:20:52.000-0600

The patch is updated:
1) to the current CVS (dated 2004-12-21 12:00:00 GMT-6);
2) suspend of call progress analysis is done for outgoing calls only.
By: Kevin P. Fleming (kpfleming) 2004-12-22 10:53:57.000-0600

New patch version is in place on my two PRI servers and working without problems.
By: twisted (twisted) 2005-01-09 22:25:59.000-0600

Gonna have to ask for an update here..

--housekeeping
By: Paul Cadach (pcadach) 2005-01-17 06:17:30.000-0600

Patch is updated. Last one applies to the current CVS cleanly (just with some fuzzies).
By: Mark Spencer (markster) 2005-01-20 22:47:09.000-0600

Added to CVS, thanks!
By: Russell Bryant (russell) 2005-01-20 23:18:02.000-0600

not in 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:22:47.000-0600

Repository: asterisk
Revision: 4865

U   trunk/channels/chan_zap.c

------------------------------------------------------------------------
r4865 | markster | 2008-01-15 15:22:47 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge zap PRi call progress fixes (bug ASTERISK-2750)

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

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