Adding tm function t_reply_by_callid

[MayamaTakeshi]

Summary
This is to permit to use opensips as a UAS and "park" incoming calls on it by replying to INVITEs using t_reply(180, "Ringing") or t_reply(183, "Session Progress"). Then later when we get CANCEL or BYE for the INVITE transaction, to be able to send a reply to that transaction (that would be usually a "487 Request Terminated'").

This is based on this discussion:
https://opensips.org/pipermail/users/2022-October/046310.html
(I'm not the OP, I just have a similar use case).

Details
This PR implements new function t_reply_by_callid on module tm.
Basically, I want to act on an INVITE and reply to it with '180 Ringing'
Then, later when the INVITE is cancelled by CANCEL or BYE, I want to be able to reply with '487 Request Terminated' to the original transaction.
The current way to permit this (as discussed in the mailing list thread is):

• create a transaction for the INVITE and store the trans_id in a database with the callid as retrieval key.
• when we receive CANCEL/BYE mark the transaction as cancelled in the database
• periodically check the database and send either '408 Request Timeout' or '487 Request Terminated'

So the motivation is:

• to avoid having to poll a database for pending transactions
• to avoid having to use mi interface (requiring an external app/script)

Solution
With t_reply_by_callid, everything can be done by opensips.cfg without need of database or external app/script.

Sample usage: https://pastebin.com/dhKm6TDi

I tested 3 scenarios using sipp:

• INVITE and CANCEL (https://pastebin.com/6b5AHyYh)
• INVITE, no answer and BYE (https://pastebin.com/HXD0WuBC)
• INVITE and transaction timeout (https://pastebin.com/0WbfGRxr)

Functional tests were performed respectively as:

sipp -s LOCAL_PARK -i 127.0.0.1 -p 5002 -sf invite_cancel_uac.xml -r 200 -l 600 127.0.0.1 -m 1

sipp -s LOCAL_PARK -i 127.0.0.1 -p 5004 -sf invite_no_answer_bye_uac.xml -r 200 -l 600 127.0.0.1 -m 1

sipp -s LOCAL_PARK -i 127.0.0.1 -p 5006 -sf invite_timeout_uac.xml -r 200 -l 600 127.0.0.1 -m 1

Then I removed the "-m 1" option which limits sipp to generate a single call and the load tests (ongoing) reached millions of calls without issues so far.

Compatibility
There should be no compatibility issues as we don't modify any existing underlying function.
We just create and expose a new function using the code that already exist.

[bogdan-iancu]

@MayamaTakeshi , let me think of this, but it a larger context, of getting the nicer transactional UAS in OpenSIPS. Your t_reply_by_callid is a part of it, but I'm considering a new function like tm_start_uac() to be called upon receiving the request/INVITE - this will replace the abused t_wait_for_new_branches() for keeping the transaction alive ; even more, we can image starting a timer, so there is a 408 timeout from TM if such a UAS transaction does not get replied in a certain amount of time.