Since on the topic of tsilo:

1. I watched Federico’s presentation on it from 2015, and his examples insinuate that it is necessary to store the index and label of a suspended transaction in some external vehicle, e.g. htable, for use with ts_append_to(). Why would one do this when it is possible to call ts_append() based on R-URI alone?

2. The appropriate pattern of interaction between tsilo and http_async_client — which I imagine to be a rather common use-case — is rather unclear.

If I use http_async_query() to call out to a PN service, with $http_req(suspend) = 1, what should happen to the current instance of SIP request processing?

That is to say:

request_route {
   . . .

   t_check_trans();

   if(is_method(“REGISTER”)) {
      . . .

      save(“location”, “0x06”);

      if(ts_append(“location”, “$tu”)) {
         xlog(“success”);
      }
      return;
   }

   else if(is_method(“INVITE”)) {
      # PN stuff.

      ts_store(“$var(uri)”);

      http_async_query(“http://url”, “PUSH_REPLY”);

      return; # <— ???
   }
}

route[HTTP_PUSH_REPLY] {
   . . .

    if(!t_relay())
       sl_reply_error();
}

I should add that this proxy front-ends a registrar, but is not in itself a registrar. It contains a shadow registrar - hence the save() calls - in order to be able to take advantage of the ’tsilo’ module, given its dependency on registrar/usrloc.

This leads to the difference that the gateway receives requests with RURIs that have already been resolved to a contact binding elsewhere, so there are no lookup() calls. How should this play into the http_async_client workflow?