call: Fix delayed (auto) answer if awaiting PRACK

[maximilianfridrich]

On an incoming call, if autoanwer is configured and we have sent a 183 containing SDP, we have to await the PRACK before we are allowed to send a 200 OK (RFC 3262 section 3 - last paragraph).

With autoanswer configured, it could happen that we try to call call_answer while we are still awaiting a PRACK. This commit fixes this.

[maximilianfridrich]

I hate to say it, but I was not able to reproduce the failing thread sanitizer check on my machine and neither by running the workflow in a docker container with act.

I am not as familiar with this new check, but the output seems to hint at fakevideo.c, not anything PRACK related.

[maximilianfridrich]

Ok, the data race is because the sdp_media->raddr is written in msg.c:media_decode() (e.g. when an INVITE is received) by the main thread and is read in the fakevideo thread when sending a video in video.c:encode_rtp_send()->packet_handler(). In this function, the mutex vtx->lock_tx is locked before reading the sdp_media->raddr, but the main thread doesn't know anything about this mutex.

Still, this doesn't have anything to do with this small fix for the autoanswer handling.

[sreimers]

Should be fixed by: #2474

[maximilianfridrich]

Thanks for the fix @sreimers. I rebased and it is working now.