Not receiving BYE request when I hang up the phone

[TRobbins]

I am on Asterisk 15.6.1 and still using the classic sip (not pjsip) stack. We are having our asterisk server initiate a call out to a phone through a twilio trunk. When the phone user hangs up the phone some time before the 3-minute mark of the phone call, I see that my asterisk server does receive the BYE request. However, if the phone user doesn’t hang up till after the 3-minute mark, then the BYE request is not seen by our Asterisk server. But, the twilio logs indicate that they are sending the BYE request, and in fact, they keep sending it, because they aren’t receiving a 200 response from asterisk. I do have sip logging enabled, and that logging does not indicate that Asterisk is even receiving the BYE request. So, I’m confused regarding this discrepancy, with how twilio says they are sending the BYE, but Asterisk doesn’t seem to think so, and also how the 3-minute mark of a phone call would come into play in triggering this bug.

I’ve attached a screenshot of the pcap log file, which came from twilio. As you can see in this screenshot, when the it’s more than 3 minutes on the phone call, there is no 200 from Asterisk and Twilio keeps sending the BYE. I would also send the working, less-than-3-minute pcap log, but this forum is restricting me to one screenshot

I am wondering what is so special about the 3-minute mark. Is there maybe some kind of Asterisk or network-level timeout that is occurring, perhaps?

[jcolp]

Are you behind a NAT or firewall? There is no timeout within chan_sip for this, and you would still see such a request if it came in - so the problem is external. It could be a UDP pinhole being closed by NAT/firewall for example causing the BYE to get blocked.

[TRobbins]

We are in aws, and now that I check, our security group rules do not have an explicit rule to allow twilio to talk to them, yet it works for at least 3 minutes, and rtp traffic appears to work even after 3 minutes (as i can see it flowing when i have rtp debug enabled). Nevertheless, I added a rule to see if it would help, but I still have the issue.

This is a good suggestion though, and I’m going to keep looking at other firewall-type issues for a bit, as that does seem like it might be some type issue like that.

[jcolp]

RTP traffic is a constant ingress and egress flow of traffic which keeps pinholes/mappings open. SIP traffic is not constant unless certain things cause it to be (for example qualify support being enabled).