[SR-Users] REGISTER with http_async_client ?

Cyril Ramière cyril.ramiere at gmail.com
Thu Feb 3 11:26:14 CET 2022 

You said to handle the registrations inside a background process, how do
you achieve that?

In fact I already tried to use the async framework and it wasn't working
too, got the same error.

Inside my REGISTER handling route I do :

<check for digest, if not provided -> challenge, if provided then go:>
async_task_route("AUTH_DOQUERY");


My AUTH_DOQUERY is:


route[AUTH_DOQUERY]{
    xlog("L_NOTICE", "[AUTH_DOQUERY] INIT \n\n");
    #I will put the http_client here, but since it is not working there is
no need atm.
    route(AUTH_REPLY);
}


And it still manages to produce the same critical error when entering my
AUTH_REPLY route :(


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


Le jeu. 3 févr. 2022 à 10:29, Olle E. Johansson <oej at edvina.net> a écrit :

>
>
> On 3 Feb 2022, at 09:54, Cyril Ramière <cyril.ramiere at gmail.com> wrote:
>
> Hi Olle,
>
> I prefer not to use it since you rightly pointed out that it will block
> the thread during the request
>
> Depends of course of your HTTP server… And the number of UDP/TCP
> listeners. It won’t block all listeners.
> Since registrations are less time-critical, you could handle the request
> asynchronously in a background process and thus not block the listener
> which would lead to more or less the same as using http_asynch. Just fire
> up a large amount of background processes :-)
>
> /O
>
>
> Since a lot of sip phones will register & interact with kamailio it could
> seriously hurt the performance.
>
> I will implement caching for sure regardless of the
> async/non-async-non-optimal solution, but I still hope that this issue will
> be solved.
>
> Cheers,
>
> Cyril
>
> Le jeu. 3 févr. 2022 à 07:57, Olle E. Johansson <oej at edvina.net> a écrit :
>
>>
>>
>> On 2 Feb 2022, at 23:58, Cyril Ramière <cyril.ramiere at gmail.com> wrote:
>>
>> Hi Karsten,
>>
>> Thanks for the clue, unfortunately I can't use this module because the
>> clients are "dumb" sip phones.
>>
>> The goal of my implementation is to use our application API to handle the
>> login.
>>
>> The plan was that a sip phone sends a REGISTER, I ask the API endpoint if
>> this user/password is ok to connect and allow/deny based on the reply and
>> informations provided by the API.
>>
>> Everything is relying on the fact that I can make my HTTP call when
>> handling the REGISTER, sadly for me, it doesn't work and I still can't
>> figure why.
>>
>> Try http_client. I’ve used it a lot of time for authentication. It will
>> block your thread while waiting for response, but you can handle some of
>> those issues by caching secrets for a short time with htable.
>>
>> /O
>>
>>
>> Cheers,
>>
>> Cyril
>>
>> Le mer. 2 févr. 2022 à 19:49, Karsten Horsmann <khorsmann at gmail.com> a
>> écrit :
>>
>>> Hi Cyril,
>>>
>>> This Kamailio module could imho do the same
>>>
>>> https://www.kamailio.org/docs/modules/devel/modules/auth_ephemeral.html
>>>
>>>
>>> Cyril Ramière <cyril.ramiere at gmail.com> schrieb am Do., 27. Jan. 2022,
>>> 08:04:
>>>
>>>> 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
>>>
>> __________________________________________________________
>> 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
>>
> __________________________________________________________
> 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/20220203/e5ec2ea1/attachment.htm>

More information about the sr-users mailing list