18 Dec
2008
18 Dec
'08
9:43 p.m.
Hello,
On 12/18/08 13:48, Iñaki Baz Castillo wrote:
> Would help the dialog module here? does the dialog module check the
> CSeq of the BYE in some way and could it prevent Kamailio from
> generating the ACC STOP action? (I don't think so).
>
> I've also asked in SIP-implementors and an idea could be generating
> the ACC STOP action when receiving the 200 OK for the BYE (and not
> when receiving the BYE itself). Of course this will be valid when the
> gateway is the recipient of the BYE (and we know the gateway is not an
> "attacker"), but this is not valid when the recipient of the BYE is an
> user since it could send no reply for the BYE.
>
> The only solution I see is:
>
> - Using the dialog module, Kamailio should check the CSeq value in the BYE.
> 1) Kamailio should forward the BYE just in case the CSeq is higher
> than the actual CSeq for this dialog direction.
> 2) Kamailio should generate the ACC STOP action just in case the CSeq
> is higher than the actual CSeq for this dialog direction.
>
> Both 1) and 2) are needed since a gateway could accept a BYE with
> wrong CSeq. In this case the call is ended but the accounting STOP
> action doesn't exist (infinite call).
>
> But I think this is too complex, isn't it?
>
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi, first of all I'm sorry for this cross-posting,
but I think it
could be interesting for any SIP proxy with accounting capabilities.
I'm thinking in the following flow in which the caller/attacker would
get an unlimited call (but a limited CDR duration):
--------------------------------------------------------------------------
attacker Kamailio (Acc) gateway
INVITE (CSeq 12) ------>
<-------- 407 Proxy Auth
INVITE (CSeq 13) ------>
INVITE (CSeq 13) ------>
<------------------- 200 Ok
<------------------- 200 Ok
<< Acc START >>
ACK (CSeq 13) ----------->
ACK (CSeq 13) ----------->
<******************* RTP ************************>
# Fraudulent BYE !!!
BYE (CSeq 10) ----------->
<< Acc STOP >>
BYE (CSeq 10) ----------->
<-- 500 Req Out of Order
<-- 500 Req Out of Order
--------------------------------------------------------------------------
The call hasn't finished, but Kamailio has ended the accounting for
this call since it received a BYE. And this BYE will generate a
correct ACC Stop action (since it matches From_tag, To_tag and
Call-ID).
If you use the flags, the BYE will be accounted only if it gets a 200OK.
If you set the failed transaction flag, then BYEs with negative replies
are accounted as well.
However, this does not stop kamailio to account another BYE, which may
have 200ok or other reply code. It is the job of your billing
application to select the right BYE for computing the call duration.
I think this is *VERY* dangerous and I hope I'm
wrong.
You can set accounting for each request withing a dialog (e.g.,
re-INVITE), and you can get many times same type of event (as it is
based on method type). So keep accounting all BYEs you get in your proxy
and chose the latest that match the dialog.
I see a potential issue with NAT traversal, if the session is ended upon
receiving of a BYE, then no audio will go on even the BYE is negatively
answered, which might be good as it forces end of call by parties
(therefore a correct BYE).
Cheers,
Daniel