Respond with ACK first before hanging up call for dialog fork

[sauwming]

Attempt to fix #3234

Currently for dialog fork, the flow is like this:
sip_ua_layer -> on_dlg_forked() -> pjsua_call: send BYE -> back to sip_ua_layer: respond with ACK.

Ideally, we want the ACK to be sent first and the patch will do this. Unfortunately, it will cause a behaviour change: now it's app's responsibility to send the ACK.

As a consequence of the behaviour change, the sipp script uas-forked-200.xml to test the scenario needs to be modified.

So do you think we should change the current behaviour?

[sauwming]

Committed a new change. Please check the updated PR desc.

[nanangizz]

• The change impact can be more than a behavior change, for example, any existing apps that does not call pjsip_dlg_on_rx_response() in its forking callback will break? Also note that pjsip_dlg_on_rx_response() is specified as internal function.
• Instead of introducing new API pjsip_rdata_set_dlg(), perhaps the steps can be inserted into pjsip_dlg_fork()?
• Perhaps simply do/move the ACK sending before invoking fork callback (if it is a final response)? But perhaps we need to consider this, IIRC there was request that app can send the ACK manually for some reason.

[sauwming]

I tried another approach to address the above concerns.

So in the latest patch, app (pjsua_call) will manually send ACK inside the callback on_dlg_forked().

Pros:

• No modification within the pjsip component.
• No break if app doesn't send ACK in on_dlg_forked().

Con:

• ACK will be sent twice, once by app inside on_dlg_forked(), another by pjsip_dlg_on_rx_response(). This shouldn't cause any harm though, and it still passes the sipp test. If this is unwanted, I can perhaps introduce a boolean variable in sip_dialog to check if ack is already sent.

Let me know what you think.

[sauwming]

The last commit is to address the above con. Now ACK is only sent once.

[nanangizz]

Good idea, a safer approach.