Call Timeout bug fix/discussion
mikaelwills opened this issue · comments
Ive come across a possible bug and also made a fix but want to discuss first to see if my assumptions are correct or if there's something else causing the issue, Im using a 3cx Server.
In a nutshell, if i make a call between two dart-sip-ua clients but don't accept the call, letting it ring and time out, the client that made the call receieves a 200 OK, CallStateEnum is set to confirmed and it behaves like the call was accepted.
Whether the remote client accepts or lets the call timeout, the local client always receives a 200 OK from 3cx.
In digging into the RFC standards it seems like the UAS should be sending a 408 back if the call timed out not a 200 OK?
Heres my fix but it would be great if someone with more experience with SIP flow could point out if this is would be the right way to handle it.
What ive found is the difference between an accepted 200 and a timed out 200 is the m=audio tag in the SDP.
In an accepted 200 the audio field is: m=audio 56189 UDP/TLS/RTP/SAVPF which has a media stream port of 56189.
In a timed out 200 the audio field is: m=audio 0 UDP/TLS/RTP/SAVPF which has a media stream port of 0 which i believe is it indicating there is no audio stream.
On line 2404 in _receiveInviteResponse() in rtc_session.dart
Along with checking if the response.body is null or is empty indicating there is a missing SDP, ive also pulled out the media port from the SDP and if that is 0 also terminate the call and set it to failed.
With this fix it fixes the bug in my situation and when the remote doesnt accept the local behaves properly.
My overall questions are.. is 3cx sending incorrect SIP messages back for the situation, is this a bug of 3cx and not of the dart sip-ua package meaning this fix shouldn't be added?