Leandro Dardini
2016-Sep-15 19:20 UTC
[asterisk-users] Tricking asterisk to think the call has ended, but it was continuing on the other side
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 <max.grobecker at ml.grobecker.info>:> 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 <ldardini at gmail.com> --------- > Datum: Thu, 15 Sep 2016 18:06:14 +0200 > Von: Leandro Dardini <ldardini at gmail.com> > Antwort an: Asterisk Users Mailing List - Non-Commercial Discussion < > asterisk-users at lists.digium.com> > Betreff: [asterisk-users] Tricking asterisk to think the call has > ended, but it was continuing on the other side > An: Asterisk Users Mailing List - Non-Commercial Discussion < > asterisk-users at lists.digium.com> > > > 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. >> > > ----- Ende der Nachricht von Leandro Dardini <ldardini at gmail.com> ----- > > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Join the Asterisk Community at the 13th AstriCon, September 27-29, 2016 > http://www.asterisk.org/community/astricon-user-conference > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160915/da584c32/attachment.html>
Max Grobecker
2016-Sep-16 22:39 UTC
[asterisk-users] Tricking asterisk to think the call has ended, but it was continuing on the other side
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160917/f8e3a476/attachment.pgp>
Leandro Dardini
2016-Sep-19 13:24 UTC
[asterisk-users] Tricking asterisk to think the call has ended, but it was continuing on the other side
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 <max.grobecker at ml.grobecker.info>:> 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 > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Join the Asterisk Community at the 13th AstriCon, September 27-29, 2016 > http://www.asterisk.org/community/astricon-user-conference > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160919/d6ce3802/attachment.html>