How to determine which party hangs up the calls

Hi all,

How can I determine which party hangs up the call.

As far as I know, there’s no “fool proof” way of determining that.

1 Like
1 Like

but how.

There are most switches with hangup legs.

This is VOIP, so there are lots of agents throughout the process that can hang up a call, and none of them are really productive when trying to answer this question. Every once in a while, you’ll get a note that a local extension hung up on a call, but if anything else kills the call (the trunk, Asterisk, the remote phone, etc.) you aren’t going to get any indication of why the call terminated. Most of the time, it looks like the trunk actually killed the call, but that’s just because of the way we process SIP and the way the protocol works.

Just for the record, don’t confuse how a B2BUA like Asterisk does things compared to the rest. With many softswitches/SBCs/Proxies that have call accounting they can tell you exactly who hung up the call. That’s because BYE and CANCEL are out-of-dialog transactions that are related to the current SIP transaction.

Not only can you see the source of the request but the From and To headers are also updated because if I was the one called (To user) and then I sent the BYE it shows the From user as me and then to To user as the caller.

This is part of why I don’t use Asterisk for CDRs (along with they only do completed calls) or certain functions like Call Forwarding. When a use has CF set up (which can support multiple numbers in my case) the proxies/switches deal with it so to Asterisk it’s just one call while the other systems can call the CF numbers in order (or at once) and it will track each call and create CDRs for each attempt and tag the connected one as the call.

So PSTN Caller to User A, User A CF always to User B, User B rings for 30 seconds with no Answer and User B has a CFU that is a mobile number to it calls the PSTN. Now I have a CDR/accounting record of PSTN Caller to User A then User A to User B and User B to PSTN however now I have all three CDRs for a single call

There are multiple benefits for this. 1) Asterisk still thinks this is a single call. It’s not hanging up channels and creating new channels for each leg of this call. Which reduces the load on Asterisk. 2) I can bill User A for the origination of the call. 3) I can bill User B for termination of the call. 4) I can bill User A for calling User B however I have free On-Net calling so since they are both users on the network the call between them is free. 5) As I said I have three CDRs for this call not the 10-15 Asterisk is going to generate for each exten/context the call lands on.

Just a small niggle here. BYE is in-dialog (you’re hanging up an existing session marked with call-id, from tag and to tag, where an INVITE has gotten a final response). CANCEL isn’t (we are canceling an INVITE that hasn’t yet been established into a dialog).

Asterisk’s CDR and even CEL logs can be unclear. I wish it had built-in SIP tracking. You can send HEP to HOMER (blech). I work in an environment that uses VoIPMonitor, which is very nice and shows on the call summary screen who BYE’d the call.

1 Like

Yeah, BYE shouldn’t have been in that since it is handled within the dialog. However, it is still a request so the From/To headers are going to be based on that which allows you to see who hung up the call (plus seeing the actual side of the call the request sourced from).

Unfortunately in B2BUA like Asterisk just because a channel left the call doesn’t mean the call “hung up”. The call could continue in dialplan and even end up making another Dial() request. All the while Music on Hold or other features are being used on the channel(s) still existing.

Both channels leaving the bridge will generate CDRs/CELs but not in the order of who left the bridge first, it’s more a less a race condition to which one is inserted first.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.