Tricking Asterisk To Think The Call Has Ended, But It Was Continuing On The Other Side
I am banging my head over a simple asterisk trick I was seeing on one asterisk server.
An extension dials an international premium number, the called number answers, then the extension hangups, but the call continue to run on the international number side, generating an high profit for the premium number company and a big loss for the asterisk owner.
I think some sort of “transfer” takes place, but I can’t identify how they do it and most important, how to prevent it.
Here the relevant logs:
[2016-09-08 21:00:25] VERBOSE[18771][C-0000066c] pbx.c: Executing
[0021628990XXX@dialoutbound:595] Dial(“SIP/201-boxoffice-00000f66”,
“SIP/0021628990XXX@SBC002_VirginMedia,60,T”) in new stack
[2016-09-08 21:00:25] VERBOSE[18771][C-0000066c] app_dial.c: Called SIP/0021628990XXX@SBC002_VirginMedia
[2016-09-08 21:00:27] VERBOSE[18771][C-0000066c] app_dial.c:
SIP/SBC002_VirginMedia-00000f67 answered SIP/201-boxoffice-00000f66
[2016-09-08 21:00:27] VERBOSE[18771][C-0000066c] bridge_channel.c: Channel SIP/201-boxoffice-00000f66 joined ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
[2016-09-08 21:00:27] VERBOSE[18779][C-0000066c] bridge_channel.c: Channel SIP/SBC002_VirginMedia-00000f67 joined ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
[2016-09-08 21:00:28] VERBOSE[18771][C-0000066c] bridge_channel.c: Channel SIP/201-boxoffice-00000f66 left ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
[2016-09-08 21:00:28] VERBOSE[18779][C-0000066c] bridge_channel.c: Channel SIP/SBC002_VirginMedia-00000f67 left ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
Any idea?
Leandro
5 thoughts on - Tricking Asterisk To Think The Call Has Ended, But It Was Continuing On The Other Side
The best is to get a PCAP so you can see exactly what is going on. Look into voipmonitor.org or homersip to capture all of your traffic. There are many ways that people commit fraud. If you are thinking about transfers what they do is the call the fraudulent number then they send a 302 to another number so they are now calling twice and the call is not on your network.
Maybe the client just put the call on hold. So the call technically has not ended AND the client does not need to
send or handle any RTP data. Is there any mention of “music on hold” for this channel?
Greetings
Max
—– Nachricht von Leandro Dardini ——-
No, there is no Music On Hold starting and the bad thing is the call duration reported by asterisk was just few seconds while the call duration reported by the provider was few thousand seconds, the max allowed. So they will be able to terminate the call on the asterisk side and have it run on the provider side.
Leandro
2016-09-15 19:18 GMT+02:00 Max Grobecker:
–EBOC3KGld5rQcv7as6JcC5hMTI4ad7719
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi,
OK, then it looks like the client transferred the call anywhere else. Do you see an entry in your log that refers to the bridge ID 00bd58c3-3bce-4f1b-9d79-11eb96f37260 ?
If there was a transfer, the call *may* have been bridged with the transfer destination. Also, the destination might be external, so you may see a second call starting at the time where the client left the bridge.
Max
–EBOC3KGld5rQcv7as6JcC5hMTI4ad7719
Unfortunately the only log messages regarding that channel are the “joined”
and the “left” for both legs.
VERBOSE[18771][C-0000066c] bridge_channel.c: Channel SIP/201-boxoffice-00000f66 joined ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
VERBOSE[18779][C-0000066c] bridge_channel.c: Channel SIP/SBC002_VirginMedia-00000f67 joined ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
VERBOSE[18771][C-0000066c] bridge_channel.c: Channel SIP/201-boxoffice-00000f66 left ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
VERBOSE[18779][C-0000066c] bridge_channel.c: Channel SIP/SBC002_VirginMedia-00000f67 left ‘simple_bridge’ basic-bridge
<00bd58c3-3bce-4f1b-9d79-11eb96f37260>
2016-09-17 0:39 GMT+02:00 Max Grobecker: