<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle20
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">The answer is 5: It shouldn&#8217;t really matter.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">If FS didn&#8217;t start the timer from the 200, then a call that was never ACK&#8217;d (which can last like 30 or 60 seconds with the terrible, default, SIP timer values) would have no duration. That&#8217;s not desirable, so
 starting from the 200 is the only thing that really makes much sense. Likewise for the hangup part. After sending a BYE (signifying you&#8217;re done), why would you continue to keep a call &#8220;up&#8221; until receiving a reply? Remember there&#8217;s another leg connected, and
 you wanna start shutting that leg down and moving or otherwise moving on with life (dialplan). At best you&#8217;d want both timestamps (or an indication the other side timed out), so you might do some processing after BYE, then finalize it on 200 of the BYE.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">But, this is really quite a distraction. Regardless which messages you choose to use, your times will never coincide perfectly with the others due to network latency. So if you accept you&#8217;ll always be off by
 that much, the question now becomes: how much difference is there between the various forms of measuring? Under normal circumstances, you&#8217;re looking at one network roundtrip &#43; processing. Processing times should be negligible, so the RTT is the only thing
 that matters. However, the other side doesn&#8217;t get much of a choice. BT cannot time off of when you _<i>sent</i>_ the 200, only when they received it. Nor can they time off of when you _<i>received</i>_ their ACK, only when they sent it. Therefore, regardless
 of which method you use, you&#8217;ll always be off by one-way latency[1].<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">As an example, with 40ms one-way latency:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;0.000: 200 OK SENT (FS)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;0.040: 200 OK RECEIVED (BT)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;0.040: ACK SENT (BT)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;0.080: ACK RECEIVED (FS)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">You hangup:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.000: BYE SENT (FS)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.040: BYE RECEIVED (BT)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.040: 200 OK SENT (BT)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.080: 200 OK RECEIVED (FS)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">They hangup:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.000: BYE SENT (BT)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.040: BYE RECEIVED (FS)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.040: 200 OK SENT (FS)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">T&#43;1.080: 200 OK RECEIVED (BT)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I&#8217;m assuming processing times are under 1ms, which seems quite reasonable. Notice how in the first part, BT gets no choice; both timestamps (OK rec&#8217;d, ACK sent) have the same ms. It&#8217;s the same for the hangup
 case, except you&#8217;re the one that doesn&#8217;t get a choice of when to measure if they hangup. Though note something interesting: sometimes it balances out. You timestamp off the 200 OK, so you&#8217;re &#8220;ahead&#8221; by 40ms (your call starts 40ms before theirs). Then you hangup,
 timestamping from when you send the BYE. Again you&#8217;re ahead, but this time your call ends 40ms before theirs, cancelling out your head start. If they hangup, though, then they get to &#8220;start late&#8221; and &#8220;end early&#8221;. I&#8217;ll show the number on this, but it rounds
 out just fine. It&#8217;d only really be a problem if FS were inconsistent and measured off sending your own packet in one case, but receiving their reply in another. That&#8217;d be a bad design I suppose.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Otherwise the only time when this really matters is when there&#8217;s something else going really wrong. A dropped packet can make one side retransmit or timeout, so waiting for a response might take significantly
 longer (many seconds if you follow the SiP spec). But if this is happening enough to matter, you&#8217;ve got a bigger issue to address. (Though since some systems didn&#8217;t address this, you could potentially find a fraud exploit by e.g. delaying or not OK&#8217;ing BYEs.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">As for processing times: Any part of the network, from the app-level to the OS, to physical phenomenon, can delay things arbitrarily. The internal design of switches can delay things. For instance, you could
 do &#8220;start = now(); sendPacket();&#8221; only to have the OS preempt your execution after now() but before sendPacket()&#8221;. Or perhaps the code is something like &#8220;runUserScripts(); doHangupWork();&#8221; &#8211; that&#8217;d explain the behaviour you described by delaying hangup, right?
 But generally, if processing times are making a real dent in things, you most likely have a more serious problem. I don&#8217;t have an answer here on FS internals, and I&#8217;m not sure you want it anyways. Do you really want to take a dependency on implementation details
 (if they aren&#8217;t documented and guaranteed)?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">But ok, let&#8217;s look at the bad case, where we measure from when we send the OK (our call starts 40ms &#8220;early&#8221;), but they hangup (our call ends 40ms &#8220;late&#8221;), and that all our traffic happens this way. In this case
 the offsets stack instead of cancelling out, so our calls are 80ms longer than theirs. If the ACD is, say, 3 minutes (180,000ms), that 80ms comes out to a 0.0% difference.[2] At least that&#8217;s what I&#8217;m getting at 2am; please doublecheck all this and decide if
 I&#8217;m accurate.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">From experience: Having used FS for years, I&#8217;ve never found timestamps to be a significant source of discrepancies. You&#8217;re far more likely to get missing CDRs due to someone&#8217;s code/screwup somewhere &#8211; it&#8217;s surprising
 how bad this can be sometimes. One big carrier, for instance, wouldn&#8217;t have all their CDRs ready when they billed, so next week&#8217;s bill might actually include calls that happened a month ago. Neato! Most people consider under 1% (or even 3%) of difference to
 be fine. Don&#8217;t worry about it, just check after some tests or some live calls and make sure you&#8217;re not seeing anything nutty. And know that by far the most common billing issue is rate disagreement, not duration.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Anyways, time in distributed systems is a complicated topic AFAIK. There&#8217;s probably some sort of special name and way for how this sort of thing is handled in telecom as it applies to any system, not just SIP.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Michael<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">1: Usually half of RTT but it&#8217;s theoretically possible for asymmetric routing to make this not so.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">2: You&#8217;d need to be doing some real short-call traffic for this to be a noticeable source of billing problems. And most short-call traffic is hungup by the sender, so the offsets cancel out.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org]
<b>On Behalf Of </b>Andrew Keil<br>
<b>Sent:</b> Tuesday, 24 November, 2015 16:16<br>
<b>To:</b> FreeSWITCH Users Help &lt;freeswitch-users@lists.freeswitch.org&gt;<br>
<b>Subject:</b> [Freeswitch-users] Re- FreeSWITCH call billing timers vs. BT SIP billing<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">To FreeSWITCH users,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">I have a question in regard to correct billing of a SIP call within FreeSWITCH (to align with Telco billing),
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">since I have asked this question below of BT (direct to their SIP compliance testing team) and received their response today.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Based on the diagram below of a simple SIP call:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">BT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FreeSWITCH<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">| --- INVITE ------&gt; |<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">| &lt;-- 100 Trying --- |<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">| &lt;-- 200 OK ------- |<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">| --- ACK ---------&gt; |<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">| &lt;-- RTP ---------&gt; |<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">| --- BYE ---------&gt; |<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">| &lt;-- 200 OK ------- |<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">In the above diagram shows an inbound call from BT to FreeSWITCH.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Which of the below statements are correct (2 out of the 4 should be correct):<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">1)&nbsp;&nbsp; The answer (or connect) timer should start from when FreeSWITCH sends the &#8220;200 OK&#8221; to indicate that the call is connected?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">2)&nbsp;&nbsp; The answer (or connect) timer should start from when FreeSWITCH receives the ACK message back from BT (after sending the &#8220;200 OK&#8221; to indicate that the call was connected)?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">3)&nbsp;&nbsp; The timer for call duration should end when FreeSWITCH receives the &#8220;BYE&#8221; message from BT?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">4)&nbsp;&nbsp; The timer for call duration should end when FreeSWITCH sends the &#8220;200 OK&#8221; to BT (after it received the &#8220;BYE&#8221; message from BT)?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">If the call was reversed ie. an outbound call made from FreeSWITCH to BT (simply swap BT and FreeSWITCH in the above diagram)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Which of the below statements are correct (2 out of the 4 should be correct):<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">1)&nbsp;&nbsp; The answer (or connect) timer should start from when FreeSWITCH receives the &#8220;200 OK&#8221; to indicate that the call is connected?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">2)&nbsp;&nbsp; The answer (or connect) timer should start from when FreeSWITCH sends the ACK message back to BT (after receiving the &#8220;200 OK&#8221; to indicate that the call was connected)?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">3)&nbsp;&nbsp; The timer for call duration should end when FreeSWITCH sends the &#8220;BYE&#8221; message to BT?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">4)&nbsp;&nbsp; The timer for call duration should end when FreeSWITCH receives the &#8220;200 OK&#8221; from BT (after it sent the &#8220;BYE&#8221; message to BT)?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">BT's response:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">...<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">...<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Therefore, when looking at FreeSWITCH this becomes more interesting, if I base BT's response to be true and correct.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Since currently the events generated at the end of a call CHANNEL_HANGUP and CHANNEL_HANGUP_COMPLETE, which align as follows:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">CHANNEL_HANGUP when BYE received or sent<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">CHANNEL_HANGUP_COMPLETE when 200 OK sent or received
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Which brings me to my actual question:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">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)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">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?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Here is a snipet of the CHANNEL_HANGUP_COMPLETE variables:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">variable_duration:14<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">variable_billsec:14<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">...<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">variable_billmsec:14041<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">...<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">variable_billusec:14041103<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">...<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">variable_answerusec:58543<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">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.&nbsp; I know this is not recommended,
 however it is just to explain this case.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">As you can see the call duration and all the billing variables show the time up to CHANNEL_HANGUP_COMPLETE not CHANNEL_HANGUP.&nbsp; However, the interesting variable is: variable_answerusec,
 which seems correct up to CHANNEL_HANGUP.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">I would appreciate any comments regarding this since obviously I would like the call durations on FreeSWITCH to match BT.&nbsp;
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-family:&quot;Courier New&quot;">Andrew Keil<o:p></o:p></span></p>
</div>
</body>
</html>