In order to explain why this is needed, I've prepared a new test scenario: https://github.com/kamailio/kamailio-tests/pull/19

This sees an HTTP request being performed in a reply route, using `http_async_client` and with suspension of the transaction. Upon landing into the HTTP reply route, the transaction is suspended for a second time while a new `http_async_query()` is performed.

Without the change in this PR, the suspension during the second query, even though it's logged as happened, doesn't have effect on `t_continue_helper()` which continues processing the reply. The reply is so sent out and when the HTTP reply route is reached afterwards the transaction exists but it's already in terminated state.

An example of .cfg (as used in the example test scenario):

``` request_route { if (is_request()) { if (is_method("INVITE")) { t_newtran(); t_on_reply("INVITE_REPLY"); t_relay("127.0.0.1", "5080"); exit; } else if (is_method("ACK")) { t_relay("127.0.0.1", "5080"); exit; } } drop; }

onreply_route[INVITE_REPLY] { xlog("L_INFO", "================ INVITE_REPLY ==================\n"); if (status=~"200") { http_async_query("http://127.0.0.1:8080/", "HTTP_REPLY1"); } }

route[HTTP_REPLY1] { xlog("L_INFO", "================ HTTP_REPLY1 ==================\n"); if ($http_ok) { xlog("L_INFO", "HTTP GET REPLY1: $http_rs - Response: $http_rb\n"); http_async_query("http://127.0.0.1:8080/", "HTTP_REPLY2"); sl_send_reply("200", "OK"); exit; } else { xlog("L_ERR", "HTTP error: $http_err\n"); } }

route[HTTP_REPLY2] { xlog("L_INFO", "================ HTTP_REPLY2 ================== DONE\n"); } ```

The debug log before the change:

``` 6(32) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction found 6(32) DEBUG: http_async_client [async_http.c:235]: async_http_cb(): resuming transaction (44930:409999179) 6(32) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction found 6(32) DEBUG: tm [t_suspend.c:364]: t_continue_helper(): continuing from a suspended reply - resetting the suspend branch flag

6(32) INFO: <script>: ================ HTTP_REPLY1 ================== 6(32) INFO: <script>: HTTP GET REPLY1: 200 - Response:

Now it calls async_send_query():

6(32) DEBUG: tm [t_suspend.c:113]: t_suspend(): this is a suspend on reply - setting msg flag to SUSPEND 6(32) DEBUG: tm [t_lookup.c:1034]: t_check_msg(): msg (0x7f48b3cd6b60) id=2/27 global id=2/27 T start=0x7f48b3cd34d8 6(32) DEBUG: tm [t_lookup.c:1109]: t_check_msg(): T (0x7f48b3cd34d8) already found for msg (0x7f48b3cd6b60)! 6(32) DEBUG: tm [t_suspend.c:121]: t_suspend(): found a a match with branch id [0] - cloning reply message to t->uac[branch].reply 6(32) DEBUG: tm [t_suspend.c:133]: t_suspend(): saving transaction data

6(32) DEBUG: http_async_client [async_http.c:469]: async_send_query(): transaction suspended [44930:409999179]

(index and label are as expected)

6(32) DEBUG: http_async_client [async_http.c:625]: async_push_query(): query sent [http://127.0.0.1:8080/] (0x7f48b3cdfa08) to worker 1

Here it should have suspended, but it's actually continuing in the reply route:

6(32) DEBUG: tm [t_suspend.c:408]: t_continue_helper(): restoring previous environment 6(32) DEBUG: tm [t_suspend.c:435]: t_continue_helper(): t is not local - relaying reply with status code: [200] ```

After more testing, in particular with multiple http_async_client workers, I've pushed some changes to ensure t_continue is not locked and the state correctly handled if the route execution suspends again the transaction. I've also moved the changes to _after_ resetting the fake environment, in order to clean it.

Thanks Daniel,

Have you looked also at re-suspending requests? It may just works, because request processing does not imply any forwarding of the message after config route execution, like happens for replies.

Yes, re-suspending requests just works, and used it in the past.

If the commit makes it coherent (i.e., re-suspending for requests and replies has similar behaviour), then the PR can be merged if no other comments.

Yes, with these changes re-suspending a reply becomes possible and similar to re-suspending a request.

I'm adding a test case with requests suspended twice in `kamailio-tests`.

Will leave this open a little longer to give me the chance to do more testing and for further comments.

@giavac pushed 1 commit.

a8f52fd86a59f8f411ebc063f09eb54cb3047b6c tm: t_reply.c - received_reply() done if suspended after route

Merged #2721 into master.