Hi Cyril,
happy to hear that you solved the problem.
About switching back to request_route type is not possible, it has to do
with the kamailio mechanism to suspend transactions. The callback route is
always a failure route.
The solution for rtpengine is either to call rtpengine_offer explicitly
Hi Federico,
Thank you, this was the solution!
You were right about trying to log $T(reply_code), this triggers the
critical error and sends a 500 internal server error message.
Since I was using the same xlog line across my entire code, $T(reply_code)
was called multiple times, I didn't think
Hi Cyril,
I tried your script and changing
sl_send_reply("200","OK");
with
send_reply("200","OK") or t_reply("200","OK");
it works, a 200 OK reply is sent out.
The message
"CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked branch (-1)
for a final response in
Okay, so I have done that,
Please find here :
https://zerobin.net/?7743b78716b00c72#Jzmdq+5ZlFfZId+M/hP+52Ih0AMAMNUjeUT1cN7jL7Q=
My full config (I redacted some parts like IPs and domains), with the
minimal routing blocks to reproduce and the logs.
If you don't mind checking it, it would be
I have to admit that even looking at the debug logs I cannot understand
what's going on in your case.
As said I'm running an authentication scenario very similar to yours, being
the challenge the only difference.
What I can suggest to further digging is to reduce your configuration as
much as
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 :
challenge, if provided then go:>
> On 3 Feb 2022, at 09:54, Cyril Ramière 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
Hi Olle,
I prefer not to use it since you rightly pointed out that it will block the
thread during the request.
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
> On 2 Feb 2022, at 23:58, Cyril Ramière 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
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
Hi Cyril,
This Kamailio module could imho do the same
https://www.kamailio.org/docs/modules/devel/modules/auth_ephemeral.html
Cyril Ramière 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
Hi Federico,
Ok, I wasn't aware of this detail about suspend/resume implementation,
thanks for pointing that out.
I made a test with debug level 3 as requested, please find the raw logs
here : https://pastebin.com/y6kZiweh
I don't think there are other SIP messages interfering with the flow, I
Hi Cyril,
it is normal that the callback route is considered a failure route, this is
the internal behavior of transaction suspension/resume as implemented by
the tm module.
Are you sure that there is no other SIP message interfering with your flow?
Could you set kamailio loglevel to 3 to see what
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
Hi there,
Does anyone have a clue? I ran out of things to try and I'm stuck.
I tried the http client (non-async) with no luck, it does almost the same
thing (tmx module spitting a critical error), which is super weird.
If I remove the HTTP request everything works fine.
There should be a way to
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
16 matches
Mail list logo
