| Summary: | ASTERISK-03717: [patch] chan_zap PRI progress handling optimization | ||
| Reporter: | Paul Cadach (pcadach) | Labels: | |
| Date Opened: | 2005-03-19 23:27:24.000-0600 | Date Closed: | 2008-01-15 15:28:59.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) zap_pri_progress.diff | |
| Description: | Shortly, no PROGRESS messages or PROGRESS IE is possible on digital-only calls, and don't send unneeded PROGRESS messages when audio is being transmitted or PROCEEDING is sent. ****** ADDITIONAL INFORMATION ****** Disclaimer is on file. | ||
| Comments: | By: Mark Spencer (markster) 2005-03-20 23:23:42.000-0600 The code already checks for proceeding having already been sent. If it hasn't, we need to send PROGRESS for our audio to be heard, am I missing something? By: Paul Cadach (pcadach) 2005-03-21 00:44:20.000-0600 Current code sends PROGRESS immediately _BEFORE_ PROCEEDING, and it's wrong. All Q.931-based specifications defines backward audio channel connection on PROGRESS or other message with PROGRESS IE equal to 8 only. On CONNECT message full audio path (forward and backward) is established. So, there isn't required to send PROGRESS message when it isn't indicated by called party. Also, because B-channel still have in-band calling tones there is not a problem. And, unrestricted digital information calls isn't allows to have PROGRESS message or PROGRESS IE (tested on EuroISDN video telephone, when it switches back to audio-only mode on any PROGRESS message/IE). edited on: 03-21-05 00:44 edited on: 03-21-05 00:45 By: Mark Spencer (markster) 2005-03-26 01:45:50.000-0600 We *should* send PROGRESS before PROCEEDING because not all interfaces know about PROCEEDING (e.g. SIP) but do have a concept of PROGRESS. By: Paul Cadach (pcadach) 2005-03-26 02:00:44.000-0600 SIP have some sort of PROCEEDING - as I remember it shoud send "100 Trying" on PROCEEDING... By: petersv (petersv) 2005-03-26 02:32:33.000-0600 Any zap->sip gateway should understand enough of isdn to realise that there is a PROGRESS IE in the PROCEEDING message and take the appropriate steps. There is no need to schedule a separate PROGRESS message just to signal progress. A PROGRRESS IE with "in band audio available" should only be sent if the low/high level compatibility bits say it is appropriate (i.e. one of the audio encodings). By: Paul Cadach (pcadach) 2005-03-26 03:05:33.000-0600 As I understand Peter is agreed with me to not disturb signalling between parties. 2Peter: Internal Asterisk's event system don't allow to pass additional parameters (IEs) with messages, so PROGRESS and PROCEEDING are different control messages. My changes is to send PROCEEDING then, if requested by remote party with PROGRESS IE - PROGRESS message instead of unconditional PROGRESS then PROCEEDING sequence. By: Mark Spencer (markster) 2005-03-26 10:59:16.000-0600 Lets try phrasing this another way.... In what way is this patch actually helpful? By: Paul Cadach (pcadach) 2005-03-26 11:50:13.000-0600 This patch is a step to provide support for passing digital (clear-channel) calls through Asterisk and makes internal event flow going from PRI links be more common with a logic compatible with existing telecom signalling (PRI and SS7). Currently this patch directed to fix invalid signalling over two bridged PRI calls coming through Asterisk box. Problems with SIP could be fixed at SIP driver level, not at PRI otherwise signalling logic will be wrong. Also, my friend had troubles with AS5350 connected to Asterisk over SIP on incoming (from PSTN to VoIP) calls because Asterisk always sends "183 Session Progress" on PROCEEDING when just "100 Trying" would be enough. By: Mark Spencer (markster) 2005-03-27 16:55:07.000-0600 You convinced me. Fixed in CVS head. By: Russell Bryant (russell) 2005-04-05 04:51:30 not included in 1.0, since as I understand it, this isn't a bug fix By: Digium Subversion (svnbot) 2008-01-15 15:28:59.000-0600 Repository: asterisk Revision: 5281 U trunk/channels/chan_zap.c ------------------------------------------------------------------------ r5281 | markster | 2008-01-15 15:28:58 -0600 (Tue, 15 Jan 2008) | 2 lines Avoid excessive "PROGRESS" messages (bug ASTERISK-3717) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5281 | ||