[OpenSIPS-Users] opensips-cp CDR correlation

[Bogdan-Andrei Iancu]

Hi Brett,

Brett Nemeroff wrote:
> At Bogdan's request, I checked out the stored proc for CDR Correlation 
> in the opensips-cp project. 
>
> I see the Invite cursor declared as:
>   DECLARE inv_cursor CURSOR FOR SELECT time, callid, from_tag, to_tag 
> FROM opensips.acc where method='INVITE' and cdr_id='0';
>
> This seems like a problem to me.. Imagine a call with several invites 
> in it (SST for example). It could pick up an INVITE in the middle of 
> the call as the "initial invite" and then improperly account duration, 
> etc.
yes, actually when we wrote this procedure was on a platform where the 
re-INVITEs were not accounted, so you got only original INVITEs. But for 
your case, you can simply modify the cursor and add in the "where" 
statement "and to_tag=NULL" - this will skip the re-INVITEs.
>
> Furthermore picking the BYE:
> SELECT 1, time INTO bye_record, v_bye_time FROM opensips.acc WHERE 
> method='BYE' AND callid=v_callid AND ((from_tag=v_from_tag AND 
> to_tag=v_to_tag) OR (from_tag=v_to_tag AND to_tag=v_from_tag)) ORDER 
> BY time ASC LIMIT 1;
>
> 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?
>
> BTW, Please redirect me if it's not appropriate to ask opensips-cp 
> questions here..
so far, this is the right place :)

Regards,
Bogdan
>
> -Brett
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>