Using conference-app.zip application with Dialogic JSR 309 Connector and XMS error in a play: cant perform play no MIXER or NC found associated to this IVR container

[RomanDS]

I ran SIPp with 25 calls and got one error which indicates that the play is being issues before JOIN is completed. This test had beep.wav disabled.

12:52:58,662 ERROR com.vendor.dialogic.javax.media.mscontrol.mediagroup.DlgcPlayer - 117 DlgcPlayer::play cant perform play no MIXER or NC found associated to this IVR container O - 25 calls.zip

[hrosa]

@RomanDS I'm currently investigating if the culprit is the ringing tone that is played while caller is joining the conference.

[RomanDS]

Hello @hrosa, as we determined here at Dialogic the issue seems to be with async queue not serializing the requests for the same call-ID. We had reproduced it with just two calls into the system running our TeleStax version of TeleStax AS. Logs attached.

Let me know what you find. This is now the last issue to resolve.

Logs.zip

[deruelle]

@RomanDS Thanks. Can you confirm my understanding below ?

When a task is submitted through the AsynchronousWork on SIPApplicationSession, you're saying the scheduler there is executing the queued tasks in a random order ?

Can you help me identify which Call-ID and possibly timestamps from the logs so we can have a quicker look at that ?

[RomanDS]

Hi Jean, Not so much in a random order as much as the JOIN request gets executed. Next inline is a play (for example). What we see that before the JOIN is completed it seems that the play is being taken off the queue and executed.

I am looking for callID but cannot find it at the moment. This is a sasID=sasId = 7785d0cc-8f52-488c-8217-d883c1367ee3;Dialogic-Converged-Demo So I think the first part of it ”might be” callID?! Looks like that “MSS-Executor-Thread-3” is the thread which starts to execute before other thread with join (MSS-Executor-Thread-11) completes. At least from where we see things going. If you look at the bottom of the log file you will see the exception there that we throw. Go up from there.

If you need additional logging / clarification we might then need to get a call between you and my team here in Dialogic to explain.

Best regards, Roman

From: Jean Deruelle [mailto:notifications@github.com] Sent: Tuesday, March 8, 2016 5:48 PM To: RestComm/Restcomm-Connect Restcomm-Connect@noreply.github.com Cc: Roman Stobnicki Roman.Stobnicki@dialogic.com Subject: Re: [Restcomm-Connect] Using conference-app.zip application with Dialogic JSR 309 Connector and XMS error in a play: cant perform play no MIXER or NC found associated to this IVR container (#895)

@RomanDShttps://github.com/RomanDS Thanks. Can you confirm my understanding below ?

When a task is submitted through the AsynchronousWork on SIPApplicationSession, you're saying the scheduler there is executing the queued tasks in a random order ?

Can you help me identify which Call-ID and possibly timestamps from the logs so we can have a quicker look at that ?

— Reply to this email directly or view it on GitHubhttps://github.com/RestComm/Restcomm-Connect/issues/895#issuecomment-194003799.

[deruelle]

@RomanDS the reason behind that would be if your JSR 309 connector ask to get access to the SIP Application Session without it being "container managed". In that case the container will not be able to guarantee serialization.

I'm adding more logs to the Async Task https://github.com/RestComm/sip-servlets/commit/a046af7816bfb7e1bb0eafe7b67387ad6a899907 so we can dive deeper.

Can you retry with the patched jar attached to reupload DEBUG Logs ?

Please rename it to .jar and remove the existing sip-servlets-impl jar that you have in your distribution to copy this one attached instead. in lib directory of Tomcat or for JBoss modules/system/layers/base/org/mobicents/libs/main (you need to modify module.xml too to have the exact same name in that file for sip-servlets-impl jar) sip-servlets-impl-3.1.668-101AttrFixMoreDebugLogs.zip

[RomanDS]

Hi @deruelle , that is interesting as we had this discussion at the beginning and we did not do it this way. Here is what we do today: We are not container managed –

SipFactoryExt f = (SipFactoryExt)DlgcSipServlet.getSipFactory(); final SipApplicationSession appSession = f.createApplicationSession(false); //false = container is not managing

We use that above code as we understood this needs to be done in order to lock the calls between the Async Queue and the connector Servlet…

[deruelle]

@RomanDS can you still send the new logs so I can have a better look at what's happening under the cover ?

[RomanDS]

ok, let me run this one for you.

[RomanDS]

Hi @deruelle , tried to run it with 60 and 100cps several times and can not reproduce it with that latest debug overlay. Could I use same overlay for ApacheTomcat release were we were able to repro with 2 connections or different build is needed for that?

[RomanDS]

server.zip

These are the logs anyway.

[deruelle]

you should be able to try with the overlay.