Summary:	ASTERISK-03676: Add inband audible ringback option to Dial
Reporter:	radamson (radamson)	Labels:
Date Opened:	2005-03-13 09:04:15.000-0600	Date Closed:	2011-06-07 14:05:12
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When a call is completed via a voip provider (via iax2) to an asterisk box with IVR (such as inbound 800 number), the call is considered "completed" when the IVR answers the inbound call. If the caller presses dtmf digits to reach a wanted extension, no ringback is heard (only dead air) until the call is answered or its hung up. Adding an option to Dial such as "ra" (inband audio ringback) would resolve the issue. (LiveVoIP.com is one example where ringback is not heard following IVR answer.) ****** ADDITIONAL INFORMATION ****** The LiveVoIP.com switch is considered a "tandem" switch in normal telephony terms. Although asterisk sends an iax2 packet to it with a subclass of "Ringing", in normal telephony terms the tandem switch would not be expected to act on such control packets as the call is considered "answered"; it is the responsibility of the end nodes to handle such "ringback" requirements. Adding this option to the Dial statement would provide asterisk implementors to provide inband audio ringback when needed.
Comments:	By: twisted (twisted) 2005-03-13 23:06:03.000-0600 so the 'r' option in dial isn't sufficient?  It works for my IVR systems and provides an in-band ringing indication to the caller as expected. By: Matt O'Gorman (mogorman) 2005-03-14 02:20:42.000-0600 I thought r did send an inband ring based on your tonezone? By: radamson (radamson) 2005-03-14 06:13:03.000-0600 No, the "r" isn't consistent. The issue (I think) is the inbound call arrives from another asterisk box via iax2. When that happens and the caller presses "3000" as an example, the ivr sends the call to a Dial statement for x3000 that includes the "r" option. Asterisk sends a iax2 control packet to the service providers asterisk box expecting "it" to generate the ringback. I have a ethereal trace showing exactly that. The service providers * switch is essentially a tandem switch (in conventional telephony terms), and that switch already knows the call was answered (by the ivr). So, this is a specific case of pstn -> *(1) -> iax2 -> *(2) -> ivr, and the current logic expects *(1) to generate the ringback (the "r" option in this case causes *(2) to send a iax2 control packet to *(1) instead of generating inband ringback audio). This current implementation is fine when both * boxes are under the same mgmt control, but not fine when *(1) is managed by a third party. If the arrangement is pstn -> * -> ivr, then ringback is heard with the "r" option; there is a difference in how the "r" option is implemented, and the difference is "dependent" on how the service provider manages thier * box. (Note: some service providers do accept the iax2 control packet and generate the ringback even though their * switch is functioning as a tandem switch.) The iax2 control packet is Type: iax (4), Control subclass: RINGING (3). To hear a real live example, call me at 800-913-4304 (livevoip.com) and I'll let the ivr handle the call. Then dial x3001 (has the "r" option) during the ivr announcement and you won't hear any ringback. (Let me know if you are going to do this, otherwise I'll answer the call before the ivr kicks in.) By: Matt O'Gorman (mogorman) 2005-03-14 06:15:47.000-0600 Which versions are you using of asterisk? By: radamson (radamson) 2005-03-14 07:00:41.000-0600 As noted above, cvs-head-02/26/05. Unknown as to what the service provider is using. But, if you follow the logic of this, this is not a bug report. This is a feature request and the option to allow an * implementor to return an inband audio ringback would be usefull for other implementations besides this iax2 ivr issue. This same iax2/ivr logic (as an example) is not applied to incoming PRI calls or anything else; the logic is only applied to * -> iax2 -> *, and changing that logic is certainly not appropriate. But, providing a Dial option to specifically support inband audio ringback corrects the iax2 issue (when needed on a per implementation basis) without disturbing the current logic. (Does that make sense?) By: wsuff (wsuff) 2005-03-14 09:07:04.000-0600 Seems logical the way it was described here so that the customer gets what they expect having Ringing for their comfort level just like PSTN By: Olle Johansson (oej) 2005-03-14 09:11:24.000-0600 playtone() ? By: Mark Spencer (markster) 2005-03-14 10:15:40.000-0600 Asterisk *is* behaving correctly.  Asterisk should and does indicate ringback.  At the point that the "RINGING" signalling can no longer be passed along in-band, it MUST be rendered.  Generally speaking, once a SIP call has been answered, out-of-band ringback can no longer be transmitted.  However, Asterisk, if acting as SIP -> IAX gateway, is smart enough to know that it must generate the ringback at that point, provided that there are no codec conversions which prevent it from doing so. Therefore, this would appear to be an issue at your provider. By: radamson (radamson) 2005-03-14 11:03:15.000-0600 That doesn't make any sense at all. The call was not answered by SIP; rather by the IVR. From the service providers perspective, the call was answered and the only way to pass ringback is via inband audio across the iax2 link. 1. call arrives via iax2 and ivr answers, 2. end-to-end voip path is now in answered mode (no sip involved), 3. caller presses 3000 4. next step in ivr routes this "answered session" to Dial statement for x3000 5. * sends iax2 control msg for "ringing" and the service provider's system isn't going to do anything with it since it was already answered. Service provider is already in cut-through (end-to-end session established) 6. caller hears dead air. The argument is equivalent to trying to jam a 'ringing' control packet back through a PRI following an answered call. Not logical at all. edited on: 03-14-05 11:11 By: Mark Spencer (markster) 2005-03-14 11:19:41.000-0600 The IAX protocol does not say RINGING cannot occur after an ANSWER.  Therefore, when interworking with something which cannot handle RINGING after an ANSWER, it is the interworking device which must create the in-band RINGING, not the IVR running on IAX protocol.  Just because other protocols are too stupid to allow indications to be transmitted after an answer doesn't mean that IAX must implement the same mistakes.  Instead, it is the responsibility of the interworking device to recognize that the signalling must be converted from out-of-band to in-band in order to work with the other technology (whether SIP or PRI or whatever) and again, Asterisk does this properly if it is in the role.  If you replace your provider with a PRI -> IAX box, you will find this works properly.  Please find me on IRC if you still don't understand. By: radamson (radamson) 2005-03-15 09:33:38.000-0600 This is far to verbose to discuss on an the irc. Your last comment essentially says... just because this happens to use iax2 and I'm the architect of that protocol, I'm expecting the entire world of telephony to change their standards to meet my iax2 requirements. Not going to happen. "All" other pbx's and CO switches are based on industry standards, and those standards dictate that once a call is in answered mode, all progress tones (including ringback in this case) "have to be originated" from the end nodes; there are no exceptions, and that is based on 21 years of real-life detailed telephony engineering knowledge & experience. Pick any telephony interface standard you want for comparison and iax2 is the only exception in this case. Has nothing to do with how smart iax/sip happens to be. So, if you don't want * to comply with standards, then I guess just close this again and we'll file it in the same non-compliant bit-bucket with why the TDM04b problems have never been addressed, etc, and I'll stop posting issues to this facility. No problem. By: Mark Spencer (markster) 2005-03-15 10:23:27.000-0600 I cannot possibly be any clearer in a static medium such as the bug tracker.  If you actually read what I wrote before you typed, you'd see that what I said is that within the IAX perspective, all signalling is out of band and that when you want to interop with something else, be it PSTN or SIP or anything else, the point at which the IAX to SIP or PSTN connection occurs is where the out of band IAX signalling must be converted to in-band <your choice of protocol here> signalling.  If you have Asterisk acting as IAX to SIP or PSTN gateway, then Asterisk is already capable of performing that function.  I don't know what is at the other end of your IAX line, but if it is Asterisk then it should be performing the proper translations in the absense of lack of codec translators, misconfiguration, unforseen bug, etc.   If you want further help understanding, I again invite you to find me on IRC, call me on the phone, or attempt some other realtime, bidirectional, full duplex method of communication -- again, NOT THE BUG TRACKER.   On the other hand, if you have no desire for help or don't wish to understand why this is the way it is, stop reopening this bug.