Summary:	ASTERISK-04244: relay PROGRESS messages with cause code IE
Reporter:	klaus3000 (klaus3000)	Labels:
Date Opened:	2005-05-20 09:50:49	Date Closed:	2011-06-07 14:05:08
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-1.0.7-handleprogresscause-patch.txt ( 1) asterisk-cvs-handleprogresscause-patch.txt ( 2) libpri-1.0.7-handleprogresscause-patch.txt ( 3) libpri-cvs-handleprogresscause-patch.txt
Description:	I'm using asterisk in the following scenario: HICOM <-PRI-> Asterisk <-PRI-> Telco IF a hicom user calls a PSTN user which is busy, the Telco will send a PROGRESS message, which includes a cause code IE. This cause code IE will signal "user busy". The HICOM needs this outband indication to generate the busy tone to the PBX users. AFAIK, neither stable or CVS processes the cause code in the PROGRESS message. I want asterisk to relay the PROGRESS message with included cause code IE to the PBX. ****** ADDITIONAL INFORMATION ****** I'm unexperienced in those low level programming, thus I ask for help. How can be this achieved best? I would suggest: 1. Prepare libpri to allow sending of PROGRESS messages with cause code IE. 2. Prepare libpri to parse the cause code IE in incoming PROGRESS messages and report them asterisk. 3. Modify the zaptel channel to relay the cause code on the bridged channel. Any comments on this, before I begin to program?
Comments:	By: petersv (petersv) 2005-05-22 02:39:53 I think this status is available to the dialplan in ${HANGUPSTATUS}. This can then be forwarded by the dialplan by setting the PRI_CAUSE variable before calling Hangup on the incoming channel. You may have to catch ${DIALSTATUS} as well. We have wrapped all this in a (quite long) macro that handles the various causes. Automatically passing any progress messages during call setup is not always correct. Asterisk is a pbx and not only an isdn switch. An outgoing channel being busy does not automatically mean the incoming channel should receive a busy message. Sometimes other extensions should be tried, perhaps an ivr message sent. By: klaus3000 (klaus3000) 2005-05-23 01:13:28 Is ${HANGUPSTATUS} also set, when there is hangup yet? A PROGRESS message is not a  DISCONNET or RELEASE COMPLETE. I went through the source code last week and couldn't find any cause code handling when processing PROGRESS messages. By: petersv (petersv) 2005-05-23 01:36:58 Progress messages are bridged in pri_dchannel in PRI_EVENT_PROGRESS. Actually, I think these are sent when a progress IE is received in any message, and not only when a PROGRESS message is received. Not checked. This bridging is to provide the needed feedback during overlap dialing. It does not bridge the cause codes. I am not even sure it forwards the in-band status. I think an unconditional forwarding of the progress messages can be a good idea. There is no reason why Asterisk cannot also be close to an isdn switch. However, given that often the incoming call leg is not mapped one-to-one to a single outbound leg (think ivr:s, ringing multiple phones etc) this needs to be an option to app_dial and the bridging code. By: klaus3000 (klaus3000) 2005-05-23 02:01:57 Thinking a little more PBX-like, I would suggest, this should be handled like a RELEASE COMPLETE with "user busy". Thus, after receiving a q931 message with cause code "user busy", asterisk should hang up this call (if not done by the other party) and the Dial application should return at priority n+101. By: petersv (petersv) 2005-05-23 02:12:43 Can you actually get a "user busy" cause code in a PROGRESS message? I thought that was only possible in a RELEASE. In this case all is already handled. The cause codes from channel teardown is stored in HANGUPCAUSE and/or DIALSTATUS. I will check the standards when I get to work today. Btw, the n+101 is being phased out. Call dial with the 'n' flag an use DIALSTATUS instead. By: klaus3000 (klaus3000) 2005-05-23 03:07:21 Having a cause code in PROGRESS is allowed (Q.931, Table 3-9). And it also used, otherwise I would have no problems :-) By: petersv (petersv) 2005-05-23 07:02:50 Yes, the progress message may contain a cause code. I am not sure if it may contain _any_ cause code. Does your pstn provider not send a RELEASE or DISCONNECT with the cause code if the destination user is busy? What happens or is expected to happen after the PROGRESS message is received with a cuase code "user busy"? By: klaus3000 (klaus3000) 2005-05-23 07:17:54 I'm testing here in Austria with 2 Telcos: -- Colt is sending DISCONNECT w/ user busy -- Telekom Austria is sending PROGRESS w/ user busy This is what happens with asterisk: *nothing* The PBX user does not hear any inband tone. I do not know if asterisk does not forward the inband audio, or the HICOM does not listen to the inband audio. What should happen: I think the end user will hear the inband busy tone and will hang up the phone. Thus, the DISCONNECT message will be sent by Asterisk --> PSTN. I patched libpri to hangup the call once a PROGRESS w/ user busy is received. But I have to wait till the office closes, to connect the Asterisk Box to the Telco line and test it. By: petersv (petersv) 2005-05-23 07:57:09 Not clearing the call when the call fails due to busy sonds a bit unusual. I have never heared of that configuration before. Have you checked with the pstn provider if you can have the configuration changed? By: klaus3000 (klaus3000) 2005-05-23 09:30:52 Not yet - I want to minimize configurations at the telco side and the PBX. Just putting asterisk inbetween without configuration needs. This also eases the fallback solution without asterisk as no changes were made to the PBX and telco line. By: petersv (petersv) 2005-05-24 00:37:56 [from my email to asterisk-dev] Looking at table I.2 in q.931 the normal operation is certainly for that cause code to be received as as a DISCONNECT by the originating caller. 5.2.5.1, 5.2.5.3 and 5.2.5.4(b) reinforces this. Further, 5.3.4.1 states that DISCONNECT, not PROGRESS should be sent when sending a busy cause code with in band tones/announcements. I hope to read through the etsi specs today. By: klaus3000 (klaus3000) 2005-05-24 01:03:17 Anyway, even if it is not the recommended way, asterisk should handle this scenario. Currently if patched libpri to store the cause code on PROGRESS messages in the pri_Event structure. chan_zap also stores this cause code in the ast_channel structure. Thus, Dial() can parse the cause code on progress events and cause a hangup. I've tested in yesterday night and it worked. I will post the patch for review soon. By: petersv (petersv) 2005-05-24 01:57:52 ETSI EN 300 403-1 (the EuroISDN spec), clause 5 explicitly prohibits the sending or receiving from causing a state change: "The sending or receiving of a PROGRESS message will cause no state change to occur." I.e. Asterisk really should not hangup on account of a progress message. If this is implemented it should be as an option and marked as non-conforming. The language above is unambigous - the pstn provider is not providing EuroISDN. By: klaus3000 (klaus3000) 2005-05-24 02:40:22 > "The sending or receiving of a PROGRESS message will cause no state change to occur." From these definitions, I can not read that it is not valid to send PROGRESS with cause code. To me, this sounds like there is no associated state change on the protocol level. What will happen in normal cases: The user will hear the inband busy tone and will hang up the phone. Thus, the hangup is not triggered by the protocol, but by the user. As you said before, Asterisk is not a switch, but a PBX. In the above scenario, there are 2 ongoing calls. Thus asterisk is like a B2B UA. For the Asterisk<->Telco call, Asterisk (in particular the Dial application) is the end user. If the user (Dial) wishes to hangup the call, than this is out of the scope of Q.931 and IMO valid. By: petersv (petersv) 2005-05-24 02:49:01 ITU q.931 (and ETSI EN 300 403-1) describes isdn devices, which are not switches.  An isdn device is not really allowed to take the PROGRESS message to imply anything more than information to the user. ISDN is not a switch technology, that would be ISUP in SS7. A pbx is one of the devices isdn describes. The standard does not prohibit PROGRESS messages with cause codes. It does prohibit an ISDN device from interpreting that message to imply a state change (such as a disconnect). Of course, Asterisk can add a non-conforming option, but it should be marked as such. The correct way for your pstn provider to signla what I assume they want to singal would be a DISCONNECT woth cause code and a PROGRESS IE "in band progress message available" followed later (30s or so) by a RELEASE. By: klaus3000 (klaus3000) 2005-05-24 03:33:39 IMO Asterisk is more than a simple ISDN terminal. There is an "user" inside (the dial application) which chooses to hangup the call. We could make the hangup on PROGRESS/busy an option for the dial command. By: petersv (petersv) 2005-05-24 03:43:35 The isdn spec is written with pbx:es in mind. The rules are usually there for a reason and in this case they are clear. It seems Asterisk has to work around a specific misfeature in a pstn implementation. That setting belongs in the channel configuration rather than in all the apps and other places where channels are used. I suggest a setting in zapata.conf. It is _very_ similar in scope to using in band progress detection. One arguemnt _for_ interpreting the cause code as a disconnect would be that "in band progress information available" actually would allow the tones to be interpreted as a hangup. By: klaus3000 (klaus3000) 2005-05-24 06:53:32 suggested fix: - libpri delivers cause code to chan_zap: Should we use the cause code in the pri_event_hangup struct or should we add the cause to the pri_event_proceeding struct? - add a zapata.conf option: handleprogresscause=yes (default=no) - now, chan_zap will process the cause when processing the PRI_EVENT_PROGRESS event (if the option is set). Then, chan_zap will signal AST_CONTROL_BUSY. Who should hang_up the call: chan_zap or the application above (e.g.dial)? By: klaus3000 (klaus3000) 2005-05-30 11:14:06 For the records: I made a patch and it works. This week I'm out of office - but I will post the patch as soon as I'm back. By: klaus3000 (klaus3000) 2005-06-07 09:28:11 A patch for this problem was added into bristuff from junghanns. He hangs up the call immediatly in chan_zap instead of sending a BUSY control_frame to the pbx (as my patch does). For my the problem is solved, as I am using bristuff anyway. But If you like, I can still post my patch here if someone needs it. By: Clod Patry (junky) 2005-06-13 12:08:20 Sure, post your patch  klaus3000, it's always good to share our works, it'll be good for future reference. And if everything works now, can we close that bug? By: klaus3000 (klaus3000) 2005-06-13 13:46:04 no - don't close. I will post the patch as the problem should also be solved with vanilla Asterisk. By: klaus3000 (klaus3000) 2005-06-15 07:19:15 Hi! I've uploaded the paches for libpri and asterisk (stable+cvs). Due to lack of PRI connectivity I could not test the patch. Although it was tested on asterisk-1.0.7 patched with briStuff on a Telekom Austria BRI. The patch does the following things: - libpri delivers cause code to chan_zap - add a zapata.conf option: handleprogresscause=yes (default=no) - now, chan_zap will process the cause when processing the PRI_EVENT_PROGRESS event (if the option is set). Then, chan_zap will signal AST_CONTROL_BUSY. Thus, the call will be handled like other busy calls. By: Michael Jerris (mikej) 2005-06-26 18:49:07 Can you review this please. By: Matthew Fredrickson (mattf) 2005-06-29 13:13:09 From what I have read in Q.931, sending this particular cause code in a progress message is indeed unconforming behaviour.  However, I think that hanging up the call is probably the correct way to handle this.  I don't even think the zapata.conf flag is necessary in this case unless someone can think of a valid reason that it should default to this.  Has anybody tested these patches to make sure they work?  Also, are they disclaimed? By: klaus3000 (klaus3000) 2005-06-29 15:21:52 disclaimer is on file I've tested the patch with a BRI card and BRI-stuff patch from Junghanns. Meanwhile there is also a patch for this issue in BRIstuff included. The difference between my patch and the solution in BRIstuf is, that in patch I will send a BUSY signal to the pbx which then hangs up. The patcin in BRIstuff just hangs up immediately in the zap channel. By: Michael Jerris (mikej) 2005-06-29 16:11:33 libpri changes have hit cvs. By: Matthew Fredrickson (mattf) 2005-06-29 17:49:09 Committed, thanks :-)