call,event: add CALL_HOLD and CALL_RESUME events and fix call resume requests

[cspiel1]

This reduces complexity in the application code

• A few simple lines in baresip can reduce the complexity in the application if a call-on-hold information should be displayed.
• Fixes also multiple re-INVITES for resumes in a row if there is only one call.

[juha-h]

Sorry, but I don't understand this code sequence in call.c: if (got_offer) { const struct sdp_media *m = stream_sdpmedia(audio_strm(call->audio)); bool aurx = sdp_media_dir(m) & SDP_SENDONLY; call->got_offer = true; /* Decode SDP Offer */ err = sdp_decode(call->sdp, msg->mb, true); if (err) { warning("call: reinvite: could not decode SDP offer:" " %m\n", err); return err; } if (aurx && !(sdp_media_dir(m) & SDP_SENDONLY)) ua_event(call->ua, UA_EVENT_CALL_HOLD, call, ""); ... Since aurx == sdp_media_dir(m) & SDP_SENDONLY, isn't test if (aurx && !(sdp_media_dir(m) & SDP_SENDONLY)) always false?

[cspiel1]

Not sure what you mean. So here are two explanations:

• There are multiple other code sections where the result of a bitwise operator is used as a boolean expression. Benefit: It is the shortest form. E.g. in src/video.c

./src/video.c:1279:	if (dir & SDP_SENDONLY)

• The SDP media object where m points to may be changed by sdp_decode() in line 1834. Because the list of sdp_media is tracked by the sdp_session where call->sdp points to. The first test is true exactly if SDP_SENDONLY bit is cleared in the media direction of the audio stream. The second if the bit is set.

[juha-h]

Thanks for the explanation. I didn't understand that sdp_decode may change sdp_media_dir(m), i.e., that making the same call two times can give different result.