[OpenSIPS-Users] opensips-cp CDR correlation

[Bogdan-Andrei Iancu]

Hi Inaki,

Iñaki Baz Castillo wrote:
> El Miércoles, 29 de Abril de 2009, Bogdan-Andrei Iancu escribió:
>   
>>> Shouldn't that ordering at the end be DESC instead of ASC.. point is,
>>> don't you want the absolute FIRST invite per callid and the absolute
>>> last BYE per callid? (sure there shouldn't be much after the FIRST
>>> BYE, but still..)
>>>       
>> but "ORDER BY time ASC" will take the BYE with the smallest timestamp ->
>> the first BYE received, which should be correct IMO, as the call will be
>> terminated by the first BYE....or I'm missing something in what you are
>> saying?
>>     
>
> Always I hear "billing in a proxy" I must to show an example attack:
>
> Phone1            Proxy         Phone2
>
> INVITE CSeq:1 -----> --------------->
> <------------------- <-------- 200 OK
> ACK CSeq:1 --------> --------------->
>
> <################ RTP ##############>
>
> BYE CSeq:1 --------> --------------->
>               [ ACC DONE ]
> <------------------- <-- 400 Bad CSeq
>
>             ( audio remains )
>   
This is an old hot topic when comes to proxies (I noticed it poped again 
on the sip-implementers list).

Of course your example is valid and can happen - but what people do not 
understand is that not the proxy is doing billing!! the proxy is the one 
just collecting information about SIP events...doing billing is the job 
of some offline parties which analyses the acc data from proxy, 
validates it and generates CDRs (billing stuff).

So a proxy may account several BYEs, but the CDR generator has the duty 
in picking the right one - like searching for the first 200OK BYE, if 
not, picking the first non-200OK with a reply code that does not 
indicate a malformed BYE ( parsing, transaction, etc)..

>
>
> For "fixing" this issue, the proxy could generate the accounting just after 
> receiving the 200 OK for a BYE. 

I can give you another example, similar to yours where the BYE is valid, 
but you get an 408 timeout on server because the P2 is dead. So, that 
BYE+408 is a valid one -> what I'm saying is that accounting just after 
the BYE+200OK is not valid all the time.
> But then we can also play with an infinite 
> possibility of spoofed "Route"/"RURI" headers so the BYE is send and received 
> by the attacker itself, who replies 200 for the BYE (but it mantains the RTP 
> session with Phone2/Gateway.
>   
Yes, it is possible.

For this a proxy, using dialog info, can check the validity of the BYE 
requests (both the inbound and outbound leg) to see if it matches (not 
as SIP dialog, but as SIP route path also) the INVITE request.
For this, I have under devel such a function in the dialog module - to 
check the correctness of the sequential requests...


Also, media traffic (even if put a lot of load on the system) may offers 
valid information to be used and aggregated with the SIP acc info.

Regards,
Bogdan