On 12/20/08 13:25, Iñaki Baz Castillo wrote:
El Sábado, 20 de Diciembre de 2008, Daniel-Constantin
Mierla escribió:
On 12/20/08 11:55, Iñaki Baz Castillo wrote:
El Sábado, 20 de Diciembre de 2008,
Daniel-Constantin Mierla escribió:
> Yeah. With radius it should be easy, since
the SQL query for SOP action
> will ensure that it wasn't a previous matching BYE.
>
I don't really get it ... would it select the first or last BYE for a
call? Will it accept many BYEs for same call or will trigger failure?
You can configure the SQL "UPDATE" query for the accounting
STOP action
in radius, so for example:
- The first matching BYE will fill a row field "completed" and set it to
"1". - At the same time the SQL query has a "WHERE completed = 0".
In this way, just the first BYE will trigger an UPDATE SQL query. Any
other BYE will be discarded by MySQL server because doesn't honor the
"WHERE" clausule and will no "re-update" the accounting row.
But, in this case, the last one should be the right one.
Well, not sure of which case exactly you mean now. I think that the accounting
proxy should ensure that a fraudulent BYE can't not be the first one in
triggering the STOP action.
I see the proxy just as a reporting point, sending to accounting system
all events within a session:
- START (200ok for INVITE, confirmed - ACK)
- UPDATEs (re-INVITE, other in-session requests)
- STOP (good, bad BYEs)
Then it comes the billing application that implements the logic to deal
with different cases. Easiest one is when you have one STOP event, but
if you have more, then you have to check for reply code, cseq, etc...
The proxy is critical because of the real-time nature of the
communication. Billing can sit and digest peacefully, report abnormally
cases, etc. Many tend to load the proxy with functionalities that don't
belong there, then start complaining is not doing the job right or fast
enough ... in every system you have to get to a compromise, not only in
VoIP.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com