[SR-Users] REGISTER with http_async_client ?

Cyril Ramière cyril.ramiere at gmail.com
Wed Jan 26 16:54:48 CET 2022


Hi there,

I have a weird issue with kamailio (latest docker
image kamailio-ci:5.5.2-alpine) and http_async_client.

Before posting a lot of logs, let me describe what I want to achieve.

I have a Kamailio and a SIP Phone.

The SIP phone sends a REGISTER to kamailio, then in my routing block, I
check if I have an Authorization header.

Since I don't have an Authorization (first message), I
use "www_challenge()".
This replies to the SIP phone, and then the SIP phone sends a new REGISTER
with the correct Authorization header.

So far so good.

Now, when I get the REGISTER with Authorization header, I want to ask an
HTTP endpoint if this user is allowed to connect and check the password
using http_async_query().

The problem is that when the transaction resumes, the tmx module is unhappy
and throws this error :

30(36) CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked
branch (-1) for a final response in MODE_ONFAILURE

And a 500 error is sent back to the sip phone.
The AUTH_REPLY route is still called and I can use the $http* values.

Do you see something that I am doing wrong or missing in my logic?
Is pausing/resuming to use the async http client is allowed if I'm handling
a REGISTER transaction?

Here's a simplified version of my routing block (not far from reality):

##### SNIP

request_route{

route(AUTH);


route[AUTH]{

    if (is_method("REGISTER"){

        if(no_auth_header){

            www_challenge("$td","1");

            exit;

        }

        else{

            t_newtran();

            http_async_query("http://xxx.xxx.xxx.xxx:9000/auth?foo=bar",
"AUTH_REPLY");

        }

    }

}


route[AUTH_REPLY]{

    xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n");

}


}

##### END SNIP


Best regards!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220126/35f38e26/attachment.htm>


More information about the sr-users mailing list