-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[1.x] Sip session get stuck #3332
Comments
If you can provide replication steps (including maybe a sipp script), I'll try to have a look at what the issue might be. As I wrote in reply to the PR, I don't think the patch is a proper fix, since it would introduce different problems, and so I'd like to investigate a different solution. |
The replication steps are:
I am not really familliar with sipp, but i try to add a sipp script later. |
If these invites are offerless, then I don't think the core or alert states have anything to do with it: there wouldn't be any SDP to trigger a new PeerConnection establishment. It's much more likely an inconsistent state within the SIP plugin itself. I'll try to replicate and let you know. |
I think I have a better understanding now, and why you were trying to tinker with the alert flag. It's true, as I said, that there's no PeerConnection establishment involved, but that's apparently the very root of the issue, rather than the reason why it shouldn't happen. Basically, an offerless INVITE means no SDP and so, again, no PC: at the same time, though, when you decline the call, we invoke the I'm wondering now what the right approach would be to address this. The "easy" fix would be to handle this directly in the SIP plugin, but in practice other plugins could in some cases end up in the same situation (even though it also depends on how they handle signaling, and the same two consecutive |
@Jonbeckas can you try this diff?
This immediately resets the |
The patch seems to change the bug a bit for me, |
Mh, thinking about it, that was to be expected, and would have happened even before this patch. When a regular call is closed, the same will happen ( In theory, the most obvious fix would be to ensure we reset the |
While I think of the implications, you can give the following patch a try, which always resets the
Please let me know if you notice any regression. |
The patch works like a charm for me. |
FYI, after careful consideration I've decided this will not be the patch I'll commit, due to the considerations I've made before. I'll instead ensure that I'll let you know when a patch is ready. I'll probably prepare a PR, so that more people can test the effect on other plugins as well. |
@Jonbeckas please test the PR above, which attempts the fix in a different way. It should address both scenarios you had problems with. You may want to test more, though, just to ensure nothing else breaks. Notice I also fixed the error code we send back by default when declining: for some reason it was |
The PR works for me. |
What version of Janus is this happening on?
1.2.2; b98e3bb
Have you tested a more recent version of Janus too?
Yes, on the master branch
Was this working before?
Not sure, behaviour of the telephone system we use changed (3cx)
Additional context
If a session has been hangup, the
JANUS_ICE_WEBRTC_ALERT
flag will be set injanus_ice_webrtc_hangup
and removed in the next call injanus_ice_setup_local
which is called byjanus_plugin_handle_sdp
.For a denied incoming sip call with no sdp body, the
JANUS_ICE_WEBRTC_ALERT
will not be removed and during the following hangup thejanus_ice_webrtc_hangup
will be abortet before the plugin is notified and the establishing attribute will be set to 0, so the session will get stuck and denies all incoming calls.The text was updated successfully, but these errors were encountered: