TEL-575: do not transition state for 407#680
Conversation
| // retry with digest credentials. This is part of the normal SIP auth | ||
| // handshake, not a finalized error, so suppress the deferred state | ||
| // transition to avoid recording a 0-duration call. | ||
| state = nil |
There was a problem hiding this comment.
I think this is fine for now. But if we don't get the second invite, as its designed currently, we won't be logging the auth failure or showing it in the dashboard.. right ? Any way around that ?
There was a problem hiding this comment.
hmm, I thought that's part of the long-term plan? We don't need to log since sipfe will log the 407 response.
With current short-term fix, if there is a second invite, we are all good. If not, we'll have a hanging INCOMING record. As far as sip, 407 is a final response, the SIP transaction is complete from the server's perspective. Are we okay with this for now?
There was a problem hiding this comment.
The long term was more about logging an event for the first auth challenge. We still need to handle the case of a second invite not coming. If 407 is the final response in that case, how will billing know to end the call ?
There was a problem hiding this comment.
from billing's perspective, the call never started since the call is never active, so we should be fine in terms of billing.
It's bad user experience though (a hanging INCOMING call status). Maybe we can use a timeout to guard this 🤔
There was a problem hiding this comment.
So we send them the UpdateSIPCallStateRequest with callStatus set to SCS_INCOMING before all this happens don't we ? If that's not the case, then we are good.
There was a problem hiding this comment.
If we are sending SCS_INCOMING, we should also send either SCS_DISCONNECT or SCS_ERROR. As you suggested a timeout for the second invite might be a good approach then
hechen-eng
force-pushed
the
407-state-update
branch
from
63cf843 to
21b3575
Compare
nishadmusthafa
left a comment
nishadmusthafa
left a comment
There was a problem hiding this comment.
Thank you @hechen-eng !
2 participants
No description provided.