[SR-Users] REGISTER with http_async_client ?

[Cyril Ramière]

Hi Frederico,

(sorry for the double posting today, despite telling gmail to not put
messages from this mailing il the spam folder, it has done it again :/ )

Thanks for your reply, I tried your suggestion and sadly it has not worked,
I still have the same error.
Upon searching and digging through the logs I still can't understand why
after the http client is doing it's request, the debugger shows that we are
not in "request" route but in "failure" route instead, I don't know if this
is a consequence or a symptom of the issue.

I triple checked my mock api, it returns a http 200 and sees the request
made by the http client.

Cheers

Le jeu. 27 janv. 2022 à 16:17, Federico Cabiddu <federico.cabiddu at gmail.com>
a écrit :

> Hi,
> I'm running a scenario very similar to yours with kamailio 5.5.3 and I
> have no issue.
> The only difference with your scenario is that I don't do the challenge
> with the client, I always reply 403 and release the transaction after.
> I didn't have the time to replicate your exact scenario but it could be
> worth trying to add a t_release() after the www_challenge().
>
> Cheers,
>
> Federico
>
> On Thu, Jan 27, 2022 at 8:04 AM Cyril Ramière <cyril.ramiere at gmail.com>
> wrote:
>
>> 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!
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users at lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220131/3eb0f826/attachment.htm>