Correspondence between SIP/RTP events and ARI events

I’m trying to track down why some caller hangups don’t appear to result in ARI events. Our conference application (entirely VoIP) relies on the latter to let us know when a caller has hung up. We are handling the following ARI events which are connected with the departure of a channel:

  • ChannelHangupRequest
  • StasisEnd
  • ChannelDestroyed

I’m also collecting SIP/RTP traffic (using pjsip and rtp logging) to help diagnose what the problem(s) might be. It would be helpful to know the relationship between indications in these traffic flows, and the above events.

Just for the record, the hangup problem that people are reporting is that they hang up, but the channel continues to exist.

Colin Dixon

A BYE received over SIP is translated into a ChannelHangupRequest - as it’s requesting that the channel be hung up. As part of hanging up the channel leaves the application which yields the StasisEnd. Finally once everything is done the channel itself is destroyed and yields the ChannelDestroyed.

If you don’t receive a BYE then the other side has not told you that it has hung up.

Thank you. So nothing to with endpoint timer settings, then - only SIP. What is happening, or rather not happening, is what you suggest. We are not receiving a BYE (I can confirm this by looking at the logs), even though the caller is now receiving a dial tone (and therefore not connected to our conference system any longer).

In the case of a BYE not being received, is there any way we can expedite the checking of the channel to force some kind of disconnection event? I was looking at changing the PJSIP timer_min_se value to something like 10, in the hope that it would pick up an absence of RTP traffic, and thus trigger a notification that the channel had gone.

Aha. Just saw your reply to an earlier and related question RTP Timeout and SIP trunks.

Not looking hopeful, then…

There is an rtp_timeout option which if RTP is not received for a period of time will hang the channel up. Of course this requires that the other side not send you RTP. If to it the connection is still open it may still continue to do so, and even with session timers the SIP leg is still up so it would respond fine.

Which config file is this an option for? Can’t find the setting in the sample rtp.conf or pjsip.conf files. This sounds like what we are looking for, because when we explicitly hang up one of these ‘ghost’ channels, we get

404 Not Found
Content-type: application/json

{“message”:“Channel not found”}

So it looks like Asterisk can deduce it’s not there.

The option is in pjsip.conf:

;rtp_timeout= ; Hang up channel if RTP is not received for the specified
; number of seconds when the channel is off hold (default:
; “0” or not enabled)

It’s specified on the endpoint and was added in later versions of 13.

As for not being able to hang it up… I’d have to see the complete console output. It’s certainly possible that there’s a “ghost” channel but it would still have to have received a BYE and gone through the normal hang up stuff.

1 Like

Thank you very much for this. One final question - is this valid for V13.6.0? Or do I need to upgrade?

Yes, sorry. If I look at the endpoint in the CLI it’s there.

Thank you very much for your help!

Ah, so nearly there.

It looks like our SIP trunk endpoint is sometimes not receiving BYEs. We’re investigating, but we thought we had solved the whole problem with the pjsip endpoint settings:

rtp_timeout=5
direct_media=false

We’re not bothered about direct media, as very few calls are point to point. This all worked well until we tried originating a call to a number on the other side of the trunk, which failed due to RTP timeout, as obviously no rtp traffic was flowing. Is there any way to start the timer once the flow is established, or some other way to deal with this issue?

Thanks again. If nothing else, this has been a learning curve…

The timer is started once the SDP has been negotiated, which is when media would be expected to be flowing. There’s no other options to control behavior.

You should really get to the bottom of why you aren’t receiving the BYE though, it’s not normal. The RTP timeout option is for the reallllllly off-nominal cases where stuff has gone kaboom.

We’re on it now. Thanks again.