Summary:	ASTERISK-14890: Asterisk generates BYE at EXACTLY 900 seconds (15 min) and terminates call
Reporter:	Richard Hamnett (riksta)	Labels:
Date Opened:	2009-09-25 13:57:29	Date Closed:	2011-06-07 14:00:19
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) LWE-506524_cli-capture.txt ( 1) opensips.cfg
Description:	I have an incoming SIP call, which then dials out to another SIP trunk and the calls are bridged via asterisk. After exactly 900 seconds there is a BYE generated and the call completely drops. I have canreinvite=no specified in both the sip.conf general and for the actual trunk stanza http://office.encompassmedia.co.uk/dump.tgz has a full SIP/RTP media pcap dump for both legs of the call which you can merge within wireshark.
Comments:	By: David Woolley (davidw) 2009-09-28 08:24:29 It can take a long time to get a response, especially if you do not follow the correct reporting procedures, which is to provide sip set debug and sip set history output, with debug and verbosity both at least 4(?). Although I can't speak for the developers, I will not normally look at something that isn't uncompressed plain text, as it just takes too much time to do so. By: Richard Hamnett (riksta) 2009-09-28 08:30:07 davidw, I appreciate your comments, however with the volume of traffic flowing through our system it would be impossible to get this information from the CLI as it scrolls at an incredibly fast rate and we have no easy way to determine when the issue will occur. I will have a look at using the sip show history By: Leif Madsen (lmadsen) 2009-09-28 08:57:04 The problem with the wireshark trace alone is that we don't have the information about what Asterisk is doing and what it is seeing. We do need the SIP information per the bug guidelines when dealing with SIP issues. If you have too much traffic, then you may need to reproduce in a lab situation where you can control the traffic more easily. Otherwise there might not be much the developers can do to move this issue forward, or it might take much longer for a developer to resolve the issue. By: David Woolley (davidw) 2009-09-28 09:05:52 If you enable /var/log/asterisk/full, you can capture the trace there, without having to do any screen scraping. By: Leif Madsen (lmadsen) 2009-09-28 14:16:02 Ah, that is another method :) I tend to use:  asterisk -rvvvvvdddddg | tee /tmp/my_output.txt By: Richard Hamnett (riksta) 2009-09-29 15:00:53 Thanks guys.... Your feedback helped to track down the source of the issue. We are using OpenSIPs load balancer which uses the dispatch module to send the calls to an asterisk node in a round robin manner. In the attached file the call id we are concerned with is Call-ID: 66B6355D-AC4511DE-9169D31F-EFD16753@213.166.5.140 Looking at the CLI SIP debug output file now attached to this bug, (from my limited knowledge) I can see that Asterisk is i think generating a RE-INVITE (despite canreinvite=no being explicitly set both globally and on the peer) at 900 seconds and inside the header you see  X-asterisk-Info: SIP re-invite (Session-Timers) At this point I do not have enough knowledge to work out WHY the actual call is dropped and why asterisk creates the BYE. I am hoping that now I have managed to attach a proper log someone can kindly shed some light on this. I have also reported this to digium under our support contract; case LWE-506524_cli Cheers! By: Richard Hamnett (riksta) 2009-09-29 15:07:59 I forgot to mention in the above comment that I have found a workaround by enabling session-timers=refuse in sip.conf Naturally, I'd like to be able to find a proper resolution to this issue :) R By: David Woolley (davidw) 2009-09-30 05:21:32 canreinvite=no only applies to reinvites for the purpose of redirecting the media-streams, and is being rename accordingly.  It does not inhibit the use of reinvites where they are essential to other operations. In this case it looks like reinvite is used to reset the session timer.  As the other end is rejecting it (status 404) it doesn't seem too unreasonable that Asterisk should drop the call.  At least to me it looks like a broken implementation of session timers in the other system. By: Richard Hamnett (riksta) 2009-09-30 05:23:45 Hi davidw, thanks for the feedback. When you say the other end, can you clarify this is either the trunk provider or the opensips load balancer? I have since looked into the opensips documentation and they have a "sst" sip session timer module that I may be able to enable, but I need clarification that the issue is opensips or the trunk provider. Cheers! By: David Woolley (davidw) 2009-09-30 05:29:04 The 404 is coming from Server: "Asterisk PBX 1.6.1.0-rc4".  Possibly at 92.63.138.97:5060, although it might be responding to garbage in.  In any case, I think you need the sip debug from that machine. By: Richard Hamnett (riksta) 2009-09-30 05:31:09 92.63.138.97 is the opensips balancer. I am going to experiment with the sst and dialog module within opensips to see if I can remedy the problem. I will get back to you. By: David Woolley (davidw) 2009-09-30 05:34:15 I suspect what is happening is that the re-invite is not going to the same worker as the original invite dialogue. The 92.63.138.97 came from the Via header and may well be one step away from the actual responder. By: Richard Hamnett (riksta) 2009-09-30 05:37:58 I think you are right davidw, I don't know how familiar you are with OpenSips, but looking at http://advantia.ca/references/opensips-1.5/modules/sst/README it seems to use the dialog and sst modules to correctly handle the session timers, what do you think? Cheers By: David Woolley (davidw) 2009-09-30 05:40:53 I'm not familiar, but also, whilst this is most likely a configuration/external problem, this is the wrong place to pursue it.  It should be pursued on the support forums, IRC, or mailing list. By: Richard Hamnett (riksta) 2009-09-30 05:44:33 cheers, feel free to close By: Leif Madsen (lmadsen) 2009-09-30 10:33:10 I'm closing this issue per the discussion, however, the session-expires=refuse reminded me of another issue that oej recently closed/fixed. You may want to see if that fixes the issue at all. Thanks!