Difference between revisions of "ANSWER(312) with billsec 0"
(Created page with 'Sometimes there is CDR with ANSWER disposition, HGC 312 and billsec 0s. How to interpret this case? The following example will illustrate one such case. The call flow is from …') |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Sometimes there is CDR with ANSWER disposition, HGC 312 and billsec 0s. | Sometimes there is CDR with ANSWER disposition, HGC 312 and the billsec is 0s. | ||
[[File:answer312_0.png]] | |||
How to interpret this case? | How to interpret this case? | ||
| Line 12: | Line 14: | ||
[[File:answer312_0_1.png]] | [[File:answer312_0_1.png]] | ||
OP sends the CANCEL at the time: 10:32:54.507296 and TP sends the ANSWER at the 10:32:54.506003. The difference is 0.0001293 seconds. | |||
In this case, TP thinks the call is ANSWERED and OP thinks it CANCELLED the call. | |||
A similar situation is described in Reason header RFC https://tools.ietf.org/html/rfc3326#section-3.2 | |||
3.2 Refusing an Offer that Comes in a Response <br> | |||
A client sends an empty INVITE and receives an unacceptable offer in a 200 (OK) | |||
response. The client sends an ACK with a correctly | |||
formatted answer and immediately sends a BYE to terminate the | |||
session. The client includes a 488 (Not Acceptable Here) status code | |||
in a Reason header field.3.2 Refusing an Offer that Comes in a Response | |||
So in our case, FS should send BYE with a Reason header to TP. | |||
That reason header contains some error code and TP should handle the call accordingly. | |||
In the marked BYE packet we see: | |||
[[File:answer312_0_2.png]] | |||
e.g. FS sent the reason that ANSWER is not accepted. | |||
Sadly the TP did not honor the RFC and marked this call as ANSWERED with billsec 1s. (TP uses Speedflow's MediaCore switch). | |||
Latest revision as of 13:04, 2 April 2020
Sometimes there is CDR with ANSWER disposition, HGC 312 and the billsec is 0s.
How to interpret this case?
The following example will illustrate one such case.
The call flow is from the Origination Point (OP) to the Proxy, Proxy sends the call over Freeswitch (FS), then back through the Proxy to the Termination Point.
In short: OP -> Proxy -> FS -> Proxy -> TP
We have the following schema:
OP sends the CANCEL at the time: 10:32:54.507296 and TP sends the ANSWER at the 10:32:54.506003. The difference is 0.0001293 seconds.
In this case, TP thinks the call is ANSWERED and OP thinks it CANCELLED the call.
A similar situation is described in Reason header RFC https://tools.ietf.org/html/rfc3326#section-3.2
3.2 Refusing an Offer that Comes in a Response
A client sends an empty INVITE and receives an unacceptable offer in a 200 (OK) response. The client sends an ACK with a correctly formatted answer and immediately sends a BYE to terminate the session. The client includes a 488 (Not Acceptable Here) status code in a Reason header field.3.2 Refusing an Offer that Comes in a Response
So in our case, FS should send BYE with a Reason header to TP. That reason header contains some error code and TP should handle the call accordingly.
In the marked BYE packet we see:
e.g. FS sent the reason that ANSWER is not accepted.
Sadly the TP did not honor the RFC and marked this call as ANSWERED with billsec 1s. (TP uses Speedflow's MediaCore switch).
