Summary:	ASTERISK-03503: calls cut off when callers over iax leave messages
Reporter:	ianplain (ianplain)	Labels:
Date Opened:	2005-02-13 12:37:56.000-0600	Date Closed:	2005-02-18 18:34:14.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Hi    I have noticed a problem with voicemail, when callers are calling in over iax lines. The call seems to drop after the caller has been talking to the voicemail for about 29 - 34 seconds. The actual call duration preceeding the voicemail has no effect on how long they are able to talk for. The voicemail conf seems fine as callers over the PSTN coming in on a x100p can talk for the full 180 seconds I have setup in the voicemail.conf. It doesnt seem tied to supplier either, as one line is from telpliant the other from voip user. ****** ADDITIONAL INFORMATION ****** The CLI shows user hungup and iax debug shows cause 16 as the reason the caller hung up.
Comments:	By: Mark Spencer (markster) 2005-02-13 12:43:27.000-0600 How about attaching a trace.  Please read the bug guidelines. By: nick (nick) 2005-02-13 12:45:38.000-0600 A copy of relevant config files might be nice, too. By: Mark Spencer (markster) 2005-02-13 12:46:39.000-0600 (to enumerate, that would be iax.conf, extensions.conf and voicemail.conf at a minimum) By: Mark Spencer (markster) 2005-02-13 15:00:50.000-0600 This call is being hungup from the calling side.  What makes you think this is a bug? By: ianplain (ianplain) 2005-02-13 16:21:35.000-0600 Well my reasoning for feeing this may be a bug is that the call is not being hungup from the calling side. Yes thats what the trace shows, But I have tested this from PSTN lines and GSM mobile lines, and it fails 100% of the time. It was brought to my attention by a caller who complained that he had been cut off whle leaving a message. Also the call cuts off after approx 30 seconds of message leaving. It is not connected to the actual call duration as I altered the time before the call is passed to voicemail and the duration that can be left is the same. The cutoff has the look and feel of call supervision not being passed back through the network. I have now configured a sip peer with PSTN access and that fails the same below is the results of the test PSTN -> PSTN                        TOK PSTN -> IAX(telpliant)              Fails PSTN -> SIP(Sipgate)                Fails SIP(FWD)  -> SIP(Sipgate & FWD)     TOK IAX (FWD)  -> SIP(Sipgate)          TOK IAX(Telpliant) ->PSTN->SIP(Sipgate) Fails   All the above calls ended in the same mailbox If this is not a bug I will pass the problem onto the suppliers of my IAX/SIP services as it seems there is a problem in their networks with respect to connections to the PSTN network as it seems the call fail only when it is coming from the PSTN via a gateway. Maybe this is a UK only problem. By: Mark Spencer (markster) 2005-02-13 16:42:33.000-0600 To the best of my knowledge, there is no way that your end could initiate a hangup which would end up arriving from the other side, ergo it cannot be a bug at your end.  Are these providers using Asterisk at their end or are they using other SIP gateways, etc? By: ianplain (ianplain) 2005-02-13 17:17:33.000-0600 I m not 100% sure on how the messageing takes place on tandam calls when paced over IAX or sip networks. But based on my knowledge of ISDN and DPNSS networking the fault I have is possible and could be caused by my system or any other in the route. It happens when the answer supervision signal is not passed either directely or via an end to end message to the originating party and when all the relevent timers time out the call is torn down from the network. I will get on to my suppliers on Monday but it looks as if the problem may be with the company that supplies the PSTN access to them, Which maybe the same company but im not 100% sure of that at this time. I will be asking for the trace of the gateway which will be eather ISDN or SS7 but at least I will be able to debug that my self. BTW are the cause codes shown in the trace iax ones or ISDN ones passed on ? As cause code 16 is normal call clearing. Thanks for your help. By: Mark Spencer (markster) 2005-02-13 22:05:26.000-0600 The cause codes are indeed ISDN cause codes, so I'm going to mark this one as "not a bug" unless you are able to provide some evidence to the contrary. By: ianplain (ianplain) 2005-02-15 08:37:05.000-0600 Hi I have spoken ith the gateway supplier and have done co-op testing and it seems that there maybe and interoperabilty issue with cisco gateways. I have attached a copy of their findings. "Hi Ian, I think I know what is happening. The Cisco equipment that we use to gateway PSTN -> VoIP includes a timer to monitor the RTCP (RTP/audio control) stream, and if it detects that this has been interrupted it will disconnect the call. The primary use of this feature is to detect VoIP endpoints which 'disappear' during a call without signalling a disconnect during the call, and thereby preventing calls from being longer than they should be. It would appear that during voicemail, or indeed any application which doesnt transmit audio on a SIP call ceases RTCP transmissions at the same time as it stops sending RTP audio. This also appears to occur when a IAX->SIP conversion occurs within Asterisk. (In fact, I don't know what other network resources are in use between us and your Asterisk, so it could lie elsewhere, but I don't think so) As a result, the gateway thinks you have disappeared and the call is disconnected. Whilst we could cause temporary relief by extending this timer, this is not the solution to the problem, the answer lies in ensuring that Asterisk continues to send RTCP reports even when there is currently no media to send. " I would assume then that others may have the problem but not noticed. I accept that this is not a "bug" but as an interoperabilty issue but it may be effecting many users. Ian By: Mark Spencer (markster) 2005-02-15 10:06:34.000-0600 Then whatever is left in this should be wrapped into bug ASTERISK-2815.