Jigasi gives up on reaching the SIP server after several minutes #539
Comments
|
According to the logs after starting asterisk jigasi tried registering but timed out: |
|
Hi @damencho, yeah thats correct. The thing is, this also happens if Jigasi is running fine for weeks and the upstream system then goes unavail for some minutes (due to maintenance from another team).. I have an idea about SIP-Timers and that this behaviour may be correct regarding RFCs, but from a production point of view the SIP-Bridge to Jitsi just breaks forever (until restarted) if the upstream SIP-Service is maintained for some minutes. A Setting/Flag to have Jigasi recovery automatically would be very helpful in this case. |
|
I don't understand the problem i terms of jigasi. After the service is back jigasi retries again and is not succeeding, not sure how to recover from this. We are handling this by checking the health of jigasi, when it becomes an healthy a new i stance is scaled up and the old one goes into graceful shutdown. |
Yeah, that would be my expectation in this case too :) Example:
Is there a way to check Jigasis Health via http like for the JVBS, or is this only possible via XMPP? :) |
|
Yes, there is a health endpoint accessible via http. |
|
Do you have any idea, if it is possible to configure Jigasi respecitvely the SIP-Timer Settings in a way that Jigasi does not stop trying to Re-Register? From my point of view it would make sense to be able to configure this behaviour.. And thanks for the hint regarding the http health check, after testing and looking in the source i think i missed configuring the sipChecker to get a good status :) |
Not sure what you are talking about. There is a reconnect plugin that controls the reconnecting logic for protocol providers and there is no logic of stopping reconnect, if I remember correctly. You can enable debug logging and when you see it stops create a heapdump to try debugging why it may have stopped reconnecting. We haven't seen that in practice, but if there is an incident with the sip provider it is short or we spin up new instances. https://github.com/jitsi/jitsi/tree/master/modules/plugin/reconnect |
|
Thanks for the pointer! To me it looks as the reconnect plugin doesnt do anything when the problem occurs: The REGISTER from 13:14:01 is the last try of sending SIP Messages and after several messages like there is no more SIP from Jigasi.. But anyhow, thanks again for the hint regarding the health endpoint! |
|
You see your provider is in reconnectEnabledProviders, so if connection fails it should be detected by the reconnect plugin and continue attempts later. |
|
Right now (14:40) the only (repeating) log messages are: I still have tcpdump running and the last SIP Message is from 13:14:01 - as you can see in the logs from my last post.. Is there any special switch/configparameter neccessary to have the reconnectplugin to do its magic? :) |
|
Nope, it should be running always. Maybe there is some bug or something. A heapdump will be helpful, but I'm not sure I will have time to look at it these days. |
|
Better use the healthcheck for now |
|
I generated a heapdump with |
|
Do not attach it, as it holds the jigasi memory and configuration. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
We are using Jigasi with Asterisk (via udp on 127.0.0.1) to allow SIP-based Dialins for our Jitsi Conferences.
This works fine as long as Asterisk is already running. If Asterisk is not reachable for some minutes Jigasi wont try to REGISTER anymore and has to be restarted.
Current behavior
Expected Behavior
It would be desirable to have Jigasi try to re-establish the SIP Registration and not giving up finally.
Possible Solution
Maybe it is possible to configure the SIP-Timers behaviour to not time out?!
Steps to reproduce
Environment details
We are using Jigasi1.1.329-g04ad08fLinux respectively Container Image: jitsi/jigasi:stable-9457-2 with Asterisk 18.10.0~dfsg+~cs6.10.40431411-2 (should not matter).
The text was updated successfully, but these errors were encountered: