[Freeswitch-users] Re- FreeSWITCH call billing timers vs. BT SIP billing

[Andrew Keil]

To FreeSWITCH users,

I have a question in regard to correct billing of a SIP call within FreeSWITCH (to align with Telco billing),
since I have asked this question below of BT (direct to their SIP compliance testing team) and received their response today.

Based on the diagram below of a simple SIP call:

BT              FreeSWITCH
| --- INVITE ------> |
| <-- 100 Trying --- |
| <-- 200 OK ------- |
| --- ACK ---------> |
| <-- RTP ---------> |
| --- BYE ---------> |
| <-- 200 OK ------- |

In order to best match the BT billing records for call duration (that will be sent to my client for their SIP service) I want to make sure that our timers are correct.

In the above diagram shows an inbound call from BT to FreeSWITCH.

Which of the below statements are correct (2 out of the 4 should be correct):

1)   The answer (or connect) timer should start from when FreeSWITCH sends the "200 OK" to indicate that the call is connected?
2)   The answer (or connect) timer should start from when FreeSWITCH receives the ACK message back from BT (after sending the "200 OK" to indicate that the call was connected)?
3)   The timer for call duration should end when FreeSWITCH receives the "BYE" message from BT?
4)   The timer for call duration should end when FreeSWITCH sends the "200 OK" to BT (after it received the "BYE" message from BT)?

If the call was reversed ie. an outbound call made from FreeSWITCH to BT (simply swap BT and FreeSWITCH in the above diagram)

Which of the below statements are correct (2 out of the 4 should be correct):

1)   The answer (or connect) timer should start from when FreeSWITCH receives the "200 OK" to indicate that the call is connected?
2)   The answer (or connect) timer should start from when FreeSWITCH sends the ACK message back to BT (after receiving the "200 OK" to indicate that the call was connected)?
3)   The timer for call duration should end when FreeSWITCH sends the "BYE" message to BT?
4)   The timer for call duration should end when FreeSWITCH receives the "200 OK" from BT (after it sent the "BYE" message to BT)?

BT's response:

...
Out of the first 4 statements, numbers 2 and 3 are closest. After BT sends the ACK the call timer will start, it will then stop again when BT sends the BYE.
Out of the second 4 statements, numbers 2 and 3 are closest. After BT receives the ACK the call timer will start, it will then stop again after BT receives the BYE.
...

Therefore, when looking at FreeSWITCH this becomes more interesting, if I base BT's response to be true and correct.

Since currently the events generated at the end of a call CHANNEL_HANGUP and CHANNEL_HANGUP_COMPLETE, which align as follows:

CHANNEL_HANGUP when BYE received or sent
CHANNEL_HANGUP_COMPLETE when 200 OK sent or received

Which brings me to my actual question:

Since billing timing is done from the point of call connect (or when the ACK is received or sent after the 200 OK) to the point of receiving the BYE message (or sending it, depending on the direction of the call)
then why does FreeSWITCH return all the billing variables inside the CHANNEL_HANGUP_COMPLETE based on call timer ending when CHANNEL_HANGUP_COMPLETE is generated and not based on when CHANNEL_HANGUP is generated?

Here is a snipet of the CHANNEL_HANGUP_COMPLETE variables:

variable_duration:14
variable_billsec:14
...
variable_billmsec:14041
...
variable_billusec:14041103
...
variable_answerusec:58543

In order to test this, I delayed a Lua script after HUNGUP (or CHANNEL_HANGUP event) was detected (for about 10 seconds) prior to ending the Lua script.  I know this is not recommended, however it is just to explain this case.

As you can see the call duration and all the billing variables show the time up to CHANNEL_HANGUP_COMPLETE not CHANNEL_HANGUP.  However, the interesting variable is: variable_answerusec, which seems correct up to CHANNEL_HANGUP.

I would appreciate any comments regarding this since obviously I would like the call durations on FreeSWITCH to match BT.
If BT are not correct with their timer points, then I am happy to go back to them with some evidence to dispute their claims.

Regards,

Andrew Keil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20151124/1fef823d/attachment-0001.html