[asterisk-ss7] Charge indicator
Bruno Rodrigues de Mello
shotsbros at hotmail.com
Sat Feb 6 14:25:26 CST 2010
For more informations bellow the RFC 3398 about ACM
http://www.packetizer.com/rfc/rfc3398/
7.2.6 ACM received
Most commonly, on receipt of an ACM a provisional response (in the
18x class) SHOULD be sent to the SIP network. If the INVITE that
initiated this session contained legitimate and comprehensible
encapsulated ISUP, then the ACM received by the gateway SHOULD be
encapsulated in the provisional response.
If the ACM contains a Backward Call Indicators parameter with a value
of 'subscriber free', the gateway SHOULD send a '180 Ringing'
response. When a 180 is sent, it is assumed, in the absence of any
early media extension, that any necessary ringback tones will be
generated locally by the SIP user agent to which the gateway is
responding (which may in turn be a gateway).
If the Backward Call Indicators (BCI) parameter of the ACM indicates
that interworking has been encountered (generally designating that
the ISUP network sending the ACM is interworking with a less
sophisticated network which cannot report its status via out-of-band
signaling), then there may be in-band announcements of call status
such as an audible busy tone or caller intercept message, and if
possible a backwards media transmission SHOULD be initiated.
Backwards media SHOULD also be transmitted if the Optional Backward
Call Indicators parameter field for in-band media is set. For more
information on early media (before 200 OK/ANM) see Section 5.5.
After early media transmission has been initiated, the gateway SHOULD
send a 183 Session Progress response code.
Gateways MAY have some means of ascertaining the disposition of in-
band audio media; for example, a way of determining by inspecting
signaling in some ISUP variants, or by listening to the audio, that
ringing, or a busy tone, is being played over the circuit. Such
gateways MAY elect to discard the media and send the corresponding
response code (such as 180 or 486) in its stead. However, the
implementation of such a gateway would entail overcoming a number of
known challenges that are outside the scope of this document.
When they receive an ACM, switches in many ISUP networks start a
timer known as "T9" which usually lasts between 90 seconds and 3
minutes (see [13]). When early media is being played, this timer
permits the caller to hear backwards audio media (in the form
ringback, tones or announcements) from a remote switch in the ISUP
network for that period of time without incurring any charge for the
connection. The nearest possible local ISUP exchange to the callee
generates the ringback tone or voice announcements. If longer
announcements have to be played, the network has to send an ANM,
which initiates bidirectional media of indefinite duration. In
common ISUP network practice, billing commences when the ANM is
received. Some networks do not support timer T9.
--------------------------------------------------
From: "Gustavo Marsico" <gustavomarsico at gmail.com>
Sent: Saturday, February 06, 2010 4:28 PM
To: <asterisk-ss7 at lists.digium.com>
Subject: Re: [asterisk-ss7] Charge indicator
> I tried that several months ago with libss7, but remember that 183 with no
> 200 means that the A side will wait for a 200, so you can have the call
> active for 2 minutes in some countries (less time on others), after that
> timer expire the call should be released. If Ast receive an ACM with
> optional backward call indicators with Information In Band available set,
> it should be sent to SIP side as 183 instead 180.
>
> Is the other side an Asterisk?
>
>
> On 6 Feb 2010, at 17:17, Bruno Rodrigues de Mello wrote:
>
>> Hi Gustavo,
>>
>>
>> I think one solution for this case is send and receive the audio during
>> the
>> early media (183).
>> Asterisk when receive a ANM from pstn side not forward the 200 Ok to SIP
>> side and establish the audio during the early media (183).
>> Does anyone know if it is possible ?
>>
>> Regards,
>> Bruno Rodrigues
>> --------------------------------------------------
>> From: "Gustavo Marsico" <gustavomarsico at gmail.com>
>> Sent: Friday, February 05, 2010 11:40 PM
>> To: <asterisk-ss7 at lists.digium.com>
>> Cc: <jvalencia at chile.com>
>> Subject: Re: [asterisk-ss7] Charge indicator
>>
>>> Unfortunately Asterisk doesn't have any way to map the charge indicator
>>> in
>>> SIP. Actually, there are a couple of drafts, but nothing serious at this
>>> time.
>>> If the other side supports it, you can send a P- or X- header to let the
>>> other side knows if the call is chargeable or not.
>>>
>>> IMHO, in SIP terms, this is one of two biggest challenges for this
>>> protocol. The other is the lack of support of SUSpend RESume
>>> capabilities
>>> in the local loop side.
>>>
>>> Regards,
>>>
>>> Gustavo
>>>
>>>
>>> On 5 Feb 2010, at 22:56, Bruno Rodrigues de Mello wrote:
>>>
>>>> Hi Jorge,
>>>>
>>>> My problem is not when I receive a call but when I send a call to
>>>> telco.
>>>> I use my asterisk box like a gateway and receive sip calls to route
>>>> this
>>>> calls to PSTN.
>>>> In some cases the Telco send a ACM with charge indicator = 1 (no
>>>> charge)
>>>> and after this
>>>> the telco send a ANM.
>>>> When asterisk receive the ANM, it send a 200 Ok to SIP side and my
>>>> softswitch start bill the call.
>>>>
>>>> Anyone has a idea ?
>>>>
>>>> Regards,
>>>> Bruno Rodrigues
>>>>
>>>>
>>>>
>>>> From: Jorge Valencia
>>>> Sent: Friday, February 05, 2010 6:20 PM
>>>> To: asterisk-ss7 at lists.digium.com
>>>> Subject: Re: [asterisk-ss7] Charge indicator
>>>>
>>>>
>>>> Hi Bruno, well last year i had the same problem, it was posted here.
>>>> My
>>>> solution was modify the source, inside isup.c you need modify the code,
>>>> find this function static FUNC_SEND(backward_call_ind_transmit) and add
>>>> some lines. I think Matt was going to setup an option..anyway here is
>>>> the
>>>> code
>>>>
>>>>
>>>> static FUNC_SEND(backward_call_ind_transmit)
>>>> {
>>>> unsigned char alwayscharge= 2;
>>>> parm[0] = 0x40 | alwayscharge;
>>>> parm[1] = 0x14;
>>>> return 2;
>>>> }
>>>>
>>>> Regards
>>>>
>>>> Jorge Valencia G.
>>>> Operaciones
>>>> Will Telefonía SA
>>>> Santo Domingo 1894 - Santiago - Chile
>>>> +56 2 5720000
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>>
>>>>
>>>> --
>>>> _____________________________________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> asterisk-ss7 mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-ss7--
>>>> _____________________________________________________________________
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> asterisk-ss7 mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>>
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-ss7 mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-ss7 mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
More information about the asterisk-ss7
mailing list