asterisk users - Sep 2016 - 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>

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>

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>