Soft Deadlock in case of re-Invite

SH
Schuster Harald
Tue, Mar 6, 2018 8:24 AM

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 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----------------------- |
SH
Schuster Harald
Tue, Mar 20, 2018 1:17 PM

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----------------------- |

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 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----------------------- |
M
maddinthegreat@gmail.com
Tue, Mar 20, 2018 2:59 PM

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----------------------- |

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----------------------- |