Hi
We are currently using the PJSIP Version 2.5.5 and we always run in a soft deadlock situation. We are using SIP INFOs for sending commands from our backend to our client which uses PJSIP. The problem exists when the backend sends a SIP INFO (5) including a command to the sip client and the sip stack answers with SIP OK(6). At the same time when the sip client sends the SIP OK(6) the backend sends a re-Invite(9). The SIP OK(10) for the re-Invite is delayed due to the fact that the sip clients answers to the SIP INFO(5) with another SIP INFO(7) which is never send because of a pjsua_call.c timeout. When the re-Invite(9) is send 20 to 30ms later there is no problem and the SIP INFO(7) is send correctly. So the question is how we can avoid this soft deadlock? Is this problem known?
ERROR: pjsua_call.c !.Timed-out trying to acquire dialog mutex (possibly system has deadlocked) in pjsua_call_send_request
Backend SIP Client
01|------------------SIP Invite-------------------- >|
02|< ------------------Trying----------------------- |
03|< ------------------SIP OK----------------------- |
04|-----------------ACK---------------------------- >|
...
05|------------------SIP INFO--------------------- >|
06|< ------------------SIP OK----------------------- |
-------------------- not send start -------------------
07|------------------SIP INFO--------------------- >|
08|< ------------------SIP OK----------------------- |
-------------------- not send stop --------------------
09|----------------re-Invite----------------------- >|
... delay of 2s
10|< ------------------SIP OK----------------------- |
Hi
Does nobody have the same behavior and knows a resolution of the problem?!
Best regards
Harald
From: pjsip pjsip-bounces@lists.pjsip.org On Behalf Of Schuster Harald
Sent: Tuesday, March 6, 2018 9:25 AM
To: pjsip@lists.pjsip.org
Subject: [pjsip] Soft Deadlock in case of re-Invite
Dieser Absender hat unsere Tests zur Betrugserkennung nicht bestanden und ist möglicherweise nicht der, der er zu sein scheint. Weitere Informationen über Spoofinghttp://aka.ms/LearnAboutSpoofing
Feedbackhttp://aka.ms/SafetyTipsFeedback
Hi
We are currently using the PJSIP Version 2.5.5 and we always run in a soft deadlock situation. We are using SIP INFOs for sending commands from our backend to our client which uses PJSIP. The problem exists when the backend sends a SIP INFO (5) including a command to the sip client and the sip stack answers with SIP OK(6). At the same time when the sip client sends the SIP OK(6) the backend sends a re-Invite(9). The SIP OK(10) for the re-Invite is delayed due to the fact that the sip clients answers to the SIP INFO(5) with another SIP INFO(7) which is never send because of a pjsua_call.c timeout. When the re-Invite(9) is send 20 to 30ms later there is no problem and the SIP INFO(7) is send correctly. So the question is how we can avoid this soft deadlock? Is this problem known?
ERROR: pjsua_call.c !.Timed-out trying to acquire dialog mutex (possibly system has deadlocked) in pjsua_call_send_request
Backend SIP Client
01|------------------SIP Invite-------------------- >|
02|< ------------------Trying----------------------- |
03|< ------------------SIP OK----------------------- |
04|-----------------ACK---------------------------- >|
...
05|------------------SIP INFO--------------------- >|
06|< ------------------SIP OK----------------------- |
-------------------- not send start -------------------
07|------------------SIP INFO--------------------- >|
08|< ------------------SIP OK----------------------- |
-------------------- not send stop --------------------
09|----------------re-Invite----------------------- >|
... delay of 2s
10|< ------------------SIP OK----------------------- |
Do you wrap your lib in COM?
Regards
Martin
Von: pjsip pjsip-bounces@lists.pjsip.org Im Auftrag von Schuster Harald
Gesendet: Dienstag, 20. März 2018 14:17
An: pjsip list pjsip@lists.pjsip.org
Betreff: Re: [pjsip] Soft Deadlock in case of re-Invite
Hi
Does nobody have the same behavior and knows a resolution of the problem?!
Best regards
Harald
From: pjsip <pjsip-bounces@lists.pjsip.org
mailto:pjsip-bounces@lists.pjsip.org > On Behalf Of Schuster Harald
Sent: Tuesday, March 6, 2018 9:25 AM
To: pjsip@lists.pjsip.org mailto:pjsip@lists.pjsip.org
Subject: [pjsip] Soft Deadlock in case of re-Invite
Dieser Absender hat unsere Tests zur Betrugserkennung nicht bestanden und
ist möglicherweise nicht der, der er zu sein scheint. Weitere Informationen
über Spoofing http://aka.ms/LearnAboutSpoofing
Feedback http://aka.ms/SafetyTipsFeedback
Hi
We are currently using the PJSIP Version 2.5.5 and we always run in a soft
deadlock situation. We are using SIP INFOs for sending commands from our
backend to our client which uses PJSIP. The problem exists when the backend
sends a SIP INFO (5) including a command to the sip client and the sip stack
answers with SIP OK(6). At the same time when the sip client sends the SIP
OK(6) the backend sends a re-Invite(9). The SIP OK(10) for the re-Invite is
delayed due to the fact that the sip clients answers to the SIP INFO(5) with
another SIP INFO(7) which is never send because of a pjsua_call.c timeout.
When the re-Invite(9) is send 20 to 30ms later there is no problem and the
SIP INFO(7) is send correctly. So the question is how we can avoid this soft
deadlock? Is this problem known?
ERROR: pjsua_call.c !.Timed-out trying to acquire dialog mutex (possibly
system has deadlocked) in pjsua_call_send_request
Backend SIP Client
01|------------------SIP Invite-------------------- >|
02|< ------------------Trying----------------------- |
03|< ------------------SIP OK----------------------- |
04|-----------------ACK---------------------------- >|
05|------------------SIP INFO--------------------- >|
06|< ------------------SIP OK----------------------- |
-------------------- not send start -------------------
07|------------------SIP INFO--------------------- >|
08|< ------------------SIP OK----------------------- |
-------------------- not send stop --------------------
09|----------------re-Invite----------------------- >|
delay of 2s
10|< ------------------SIP OK----------------------- |