Getting "Unrecognized media profile" for SDP line
m=application 9 DTLS/SCTP 5000
while connecting over WebRTC from Mozila Firefox 37 under linux 64

RestComm is only listing the srflx candidate in the SDP answer for ICE-enabled calls, with wrong raddr and wrong rport parameters.

RestComm should list all host candidates and the srflx candidate should wrap the default host candidate and reflect its address and port in the raddr and rport parameters

When the Media Server is asked to perform an outbound call, the SDP offer that is generated will use the RTP/AVP profile by default, whereas WebRTC clients requires RTP/SAVP.

There are two possible ways of solving this issue: the first is through SDP renegotiation and the second is for the offer to contain the two media sessions (two m= line for RTP/AVP and RTP/SAVP) and let the client choose one.

Apparently GSM is disabled by default. It sounds like its minor overhead, so lets have it enabled by default.

At the moment, the audio mixing elements are scattered over different classes, in different hierarchy levels: Endpoint, Connection, Channels, etc.

I propose moving the mixing element to a single well-contained class, located between the endpoint and its connections.

This will allow us to expand the endpoints to choose between RTP relay type (mixer or translator) very easily.

When Restcomm using only HTTPS connector, the RQNT to the ivr endpoint uses HTTPS scheme for the URL to wav file.

14:16:54,275 DEBUG [MgcpProvider] Parsing message: RQNT 147483656 mobicents/ivr/[email protected]:2427 MGCP 1.0
N:[email protected]:2727
X:1
S:AU/pa(an=https://instance1.restcomm.com:8443/restcomm/cache/ACae6e420f425248d6a26948c17a9e2acf/d1b8f7f5dd4ee95983a2310a5cd9e77c13e6aaf61c0910f51bc3d74bd674a9c6.wav it=1)
R:AU/oc(N),AU/of(N)

In that case MMS plays only the first part of the file. For example for application 1234, plays only "Welcome to...." or sometimes "Welc....".

There is no exception at the MMS or Restcomm logs.

14:16:54,275 DEBUG [MgcpProvider] Parsing message: RQNT 147483656 mobicents/ivr/[email protected]:2427 MGCP 1.0
N:[email protected]:2727
X:1
S:AU/pa(an=https://instance1.restcomm.com:8443/restcomm/cache/ACae6e420f425248d6a26948c17a9e2acf/d1b8f7f5dd4ee95983a2310a5cd9e77c13e6aaf61c0910f51bc3d74bd674a9c6.wav it=1)
R:AU/oc(N),AU/of(N)

14:16:54,275 INFO  [JitterBuffer] Format has been changed: 8 AudioFormat[pcma,8000,8,mono]
14:16:54,275 DEBUG [MgcpProvider] Dispatching message
14:16:54,276 INFO  [MGCP] tx=147483656 Started, message= RQNT mobicents/ivr/[email protected]:2427, call agent = instance1.restcomm.com/192.168.1.151:2727
14:16:54,294 DEBUG [ResourcesPool] Allocated new player, pool size:5, free:4
14:16:54,296 INFO  [Play] (mobicents/ivr/1) Start announcement (segment=0)
14:16:54,583 INFO  [MGCP] tx=147483656 was executed normaly
14:16:54,835 INFO  [AudioPlayerImpl] (mobicents/ivr/1) End of file reached
14:16:54,836 INFO  [Play] (mobicents/ivr/1) Announcement (segment=0) has completed
14:16:54,837 INFO  [MGCP] tx=2 Started, message= NTFY mobicents/ivr/[email protected]:2427, call agent = instance1.restcomm.com/192.168.1.151:2727
14:16:54,838 INFO  [MGCP] tx=2 was executed normaly
14:16:54,855 DEBUG [MgcpProvider] Receive  message 55 bytes length
14:16:54,855 DEBUG [MgcpProvider] Parsing message: 200 2 The requested transaction was executed normally.

Find the pcap and logs from Restcomm and MMS here: https://app.box.com/s/awmz134nekp8jzsn2mosaxpgmgoy63ym

Currently we are using 1.50 which has some issues in the DHE key exchange that our iOS client uses

Currently the SDP parser always looks for the "generation" attribute in a candidate line, but such parameter is optional.

The SDP attribute ptime and maxptime are currently being bound to each rtmap in the media line.
Instead they should be bound directly to the media description, occurring once at most, as stated in RFC4566: https://tools.ietf.org/html/rfc4566#page-25

Using Mobicents RestComm (SNAPSHOT 7.2.1.600), for a few times, when calling the +1236 gather demo, call seems to be established but shortly after drops. From the logs it can be seen that SDP is truncated at some point:

(...) a=fingerprint:sha-256 BA:66:20:CE:A6:64:6A:E9:76:B0:E6:A0:1B:47:80:42:C1:CB:1E:43:4B:79:C5:13:8A:3A:54:94:72:CC:3E:96 a=ssrc:706634229 cnam ]]>

Tried to replicate later with logs in DEBUG, without success. Call log in INFO at https://gist.github.com/brainslog/b72af64632d822f1fe5a.

This is not an MMS issue, but a Bouncy Castle one. I'm just documenting it here because it might pop again in the future.

The result is that although signalling is fine, no media is returned to the caller.

Here's the stack trace:

2015-05-28 07:05:27,836 ERROR DtlsHandler DTLS handshake failed: internal_error(80)
org.bouncycastle.crypto.tls.TlsFatalAlert: internal_error(80)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.accept(Unknown Source)
at org.mobicents.media.server.impl.srtp.DtlsHandler$HandshakeWorker.run(DtlsHandler.java:337)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Handshake is taking too long! (>4000ms
at org.mobicents.media.server.impl.srtp.NioUdpTransport.receive(NioUdpTransport.java:94)
at org.bouncycastle.crypto.tls.DTLSRecordLayer.receiveRecord(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSRecordLayer.receive(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSReliableHandshake.receiveMessage(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSReliableHandshake.receiveMessageBody(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.serverHandshake(Unknown Source)
... 3 more

The proposed solution is to contribution to Bouncy Castle a NIO implementation of DTLS :)

Logs, cpu/mem usage and tcpdump of a failed call at folder /opt/incident_oct26

In light of recent developments wrt issue #30, there is the need to develop a new Scheduler based on ScheduledExecutorService that exposes an interface to submit tasks in regular time intervals or to schedule a task to be executed in a give time.

This new "ServiceScheduler" would have to co-exist with the existing Scheduler implementation.
While the old Scheduler would be responsible for executing media processing tasks (mixing, splitting and heartbeats), the new Scheduler would be responsible for processing readings from channels or scheduling RTCP events.

At first glance, classes that can take advantage of the new Scheduler are the UDP Manager, RtcpHandler and IceAgent.

It's necessary to create a monitoring platform for the Mobicents MS, capable of measuring performance in real time.

Possible statistics to be gathered:

• CPU Usage
• Mem Usage
• Number and type of active endpoints
• Data about connections between endpoints (latency, jitter, packets, octets)

The user should be able to tell the Media Server to use or not RTCP channels, via configuration file.

Add support to MGCP AUEP so that clients can query information about a specific MGCP Endpoint in the Media Server.

The specification of MGCP AUEP request can be found here.

2015-01-12 20:26:33,015 INFO AudioPlayerImpl (mobicents/ivr/1) End of file reached
2015-01-12 20:26:33,016 INFO Play (mobicents/ivr/1) Announcement (segment=0) has completed
2015-01-12 20:26:33,017 INFO MGCP tx=3 Started, message= NTFY mobicents/ivr/[email protected]:2427, call agent = gvagenas-Latitude-E6520/192.168.1.151:2727
2015-01-12 20:26:33,018 INFO MGCP tx=3 was executed normaly
2015-01-12 20:26:33,034 DEBUG MgcpProvider Receive message 55 bytes length
2015-01-12 20:26:33,034 DEBUG MgcpProvider Parsing message: 200 3 The requested transaction was executed normally.

2015-01-12 20:26:33,034 DEBUG MgcpProvider Dispatching message
2015-01-12 20:26:33,054 DEBUG MgcpProvider Receive message 71 bytes length
2015-01-12 20:26:33,055 DEBUG MgcpProvider Parsing message: DLCX 147483661 mobicents/bridge/[email protected]:2427 MGCP 1.0
C:1
I:a6

2015-01-12 20:26:33,055 DEBUG MgcpProvider Dispatching message
2015-01-12 20:26:33,055 INFO MGCP tx=147483661 Started, message= DLCX mobicents/bridge/[email protected]:2427, call agent = gvagenas-Latitude-E6520/192.168.1.151:2727
2015-01-12 20:26:33,056 ERROR RtcpPacket Received type = 71 RTCP Packet decoding falsed. offSet = 16. Packet count = 2
2015-01-12 20:26:33,056 DEBUG RtcpHandler
RECEIVED RECEIVER REPORT:
version=2, padding=false, packet type=201, length=8, ssrc=3295100647
BYE:
version= 2, padding= false, source count=1, packet type=203, length=36, ssrc= 3295100647, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0, ssrc= 0

2015-01-12 20:26:33,059 ERROR Task Negative delay.
java.lang.IllegalArgumentException: Negative delay.
at java.util.Timer.schedule(Timer.java:192)
at org.mobicents.media.server.impl.rtcp.RtcpHandler.rescheduleRtcp(RtcpHandler.java:260)
at org.mobicents.media.server.impl.rtcp.RtcpHandler.handle(RtcpHandler.java:390)
at org.mobicents.media.server.io.network.channel.MultiplexedChannel.receive(MultiplexedChannel.java:194)
at org.mobicents.media.server.io.network.UdpManager$PollTask.perform(UdpManager.java:529)
at org.mobicents.media.server.scheduler.Task.run(Task.java:122)
at org.mobicents.media.server.scheduler.Scheduler$WorkerThread.run(Scheduler.java:420)
2015-01-12 20:26:33,065 DEBUG MediaChannel audio channel 3940481173 is closed
2015-01-12 20:26:33,065 DEBUG RtcpHandler Could not send RTCP_BYE packet because channel is closed or disconnected.
2015-01-12 20:26:33,066 DEBUG ResourcesPool Released rtp connection,pool size:10,free:10
2015-01-12 20:26:33,067 INFO MGCP tx=147483661 was executed normaly
2015-01-12 20:26:33,093 DEBUG MgcpProvider Receive message 71 bytes length
2015-01-12 20:26:33,094 DEBUG MgcpProvider Parsing message: DLCX 147483662 mobicents/bridge/[email protected]:2427 MGCP 1.0
C:1
I:a7

The latency level keeps increasing for WebRTC calls.

https://groups.google.com/forum/#!msg/mozilla.dev.media/tkxeLEnBK9M/_4TMgrCShtMJ

OpenBTS only supports GSM codec. Uses the following SDP:

v=0
o=IMSI001010000000002 0 0 IN IP4 192.168.1.22
s=Talk Time
t=0 0
m=audio 16494 RTP/AVP 3
c=IN IP4 192.168.1.22
a=rtpmap:3 GSM/8000

Currently media server shows the following error for GSM codec:

19:47:29,936 INFO  [MainDeployer] [[[[[[[[[ Mobicents Media Server: release.version=3.0.0.FINAL Started ]]]]]]]]]
19:48:28,907 INFO  [MGCP] tx=147483655 Started, message= CRCX mobicents/bridge/[email protected]:2427, call agent = localhost/127.0.0.1:2727
19:48:28,924 INFO  [RtpConnectionImpl] FormatsRTPFormats{3 AudioFormat[GSM,8000,mono]}
19:48:28,928 ERROR [MGCP] tx=147483655 Failed
org.mobicents.media.server.mgcp.tx.cmd.MgcpCommandException
    at org.mobicents.media.server.mgcp.tx.cmd.CreateConnectionCmd$Preprocessor.perform(CreateConnectionCmd.java:296)
    at org.mobicents.media.server.scheduler.Task.run(Task.java:122)
    at org.mobicents.media.server.scheduler.Scheduler$WorkerThread.run(Scheduler.java:420)
19:48:28,940 INFO  [MGCP] tx=147483655 Rolled back
19:48:28,942 INFO  [Server] Global hearbeat is still alive
19:49:28,873 INFO  [Server] Global hearbeat is still alive

I know at some point GSM was a supported codec:

https://code.google.com/p/mobicents/source/browse/trunk/servers/media/codecs/gsm/src/main/java/org/mobicents/media/server/impl/dsp/audio/gsm/Decoder.java?r=16762

An issue was identified where RTP connections cannot do multiple WebRTC outbound calls.
Once the connection is pooled (after first call), following attempts to do outbound WebRTC call will result in the following error:

13:58:08,325 INFO [RtpChannel] Can not connect to remote address , please check that you are not using local address - 127.0.0.X to connect to remote
13:58:08,327 ERROR [RtpChannel]
java.nio.channels.ClosedChannelException
at sun.nio.ch.DatagramChannelImpl.ensureOpenAndUnconnected(DatagramChannelImpl.java:719)
at sun.nio.ch.DatagramChannelImpl.connect(DatagramChannelImpl.java:732)
at org.mobicents.media.server.impl.rtp.RtpChannel.setRemotePeer(RtpChannel.java:369)
at org.mobicents.media.server.impl.rtp.channels.MediaChannel.connectRtp(MediaChannel.java:506)
at org.mobicents.media.server.impl.rtp.channels.MediaChannel.connectRtp(MediaChannel.java:527)
at org.mobicents.media.core.connections.RtpConnectionImpl.setupAudioChannelOutbound(RtpConnectionImpl.java:387)
at org.mobicents.media.core.connections.RtpConnectionImpl.setOtherPartyOutboundCall(RtpConnectionImpl.java:291)
at org.mobicents.media.core.connections.RtpConnectionImpl.setOtherParty(RtpConnectionImpl.java:206)
at org.mobicents.media.core.connections.RtpConnectionImpl.setOtherParty(RtpConnectionImpl.java:163)
at org.mobicents.media.core.connections.RtpConnectionImpl.setOtherParty(RtpConnectionImpl.java:171)
at org.mobicents.media.server.mgcp.controller.MgcpConnection.setOtherParty(MgcpConnection.java:128)
at org.mobicents.media.server.mgcp.tx.cmd.ModifyConnectionCmd$Modifier.perform(ModifyConnectionCmd.java:136)
at org.mobicents.media.server.scheduler.Task.run(Task.java:122)
at org.mobicents.media.server.scheduler.PriorityQueueScheduler$WorkerThread.run(PriorityQueueScheduler.java:424)

Currently, the RtcpHandler relies on Timer to schedule two different task: one for sending RTCP reports and another to validate the list of registered SSRC. This way, each instance of RtcpHandler spans two additional threads.

A better approach is for the handler to submit these tasks to a Scheduler, which is responsible for managing the thread pool.

Need to gather statistics from a connection so that MS can reply accordingly to MGCP AUCX requests.

Starting Restcomm and then Jitsi calls RCML apps that Dials client BOB with RECORD=TRUE

First two calls are ok, clients are connected and record is working. Third call (always the third call and next calls) fails with the following:

15:37:00,571 DEBUG [MgcpProvider] Dispatching message
15:37:00,572 INFO [MGCP] tx=147483701 Started, message= RQNT mobicents/ivr/[email protected]:2427, call agent = gvagenas-Latitude-E6520/192.168.1.151:2727
15:37:00,572 DEBUG [MgcpProvider] Receive message 346 bytes length
15:37:00,572 DEBUG [MgcpProvider] Parsing message: RQNT 147483702 mobicents/ivr/[email protected]:2427 MGCP 1.0
N:[email protected]:2727
X:14
S:AU/pr(ri=file:///data/workspace/temp/731/Mobicents-Restcomm-JBoss-AS7-7.3.1.675/standalone/deployments/restcomm.war/recordings/RE845045f7a1dd41caaf57d56417c4237b.wav cb=true prt=50 pst=50 rlt=3600000 eik=1234567890*# mn=12 mx=12)
R:AU/oc(N),AU/of(N)

15:37:00,572 DEBUG [MgcpProvider] Dispatching message
15:37:00,572 INFO [MGCP] tx=147483702 Started, message= RQNT mobicents/ivr/[email protected]:2427, call agent = gvagenas-Latitude-E6520/192.168.1.151:2727
15:37:00,574 ERROR [MGCP] tx=147483702 Failed
org.mobicents.media.server.mgcp.tx.cmd.MgcpCommandException
at org.mobicents.media.server.mgcp.tx.cmd.NotificationRequestCmd$Request.perform(NotificationRequestCmd.java:151)
at org.mobicents.media.server.scheduler.Task.run(Task.java:122)
at org.mobicents.media.server.scheduler.Scheduler$WorkerThread.run(Scheduler.java:420)

And then full of :

gvagenas [3:40 PM]
15:37:00,592 WARN [RtcpHandler] RTCP timer already canceled. Scheduled report was canceled and cannot be re-scheduled.
15:37:00,592 DEBUG [MgcpProvider] Dispatching message
15:37:00,592 INFO [MGCP] tx=147483703 Started, message= DLCX mobicents/bridge/[email protected]:2427, call agent = gvagenas-Latitude-E6520/192.168.1.151:2727
15:37:00,593 DEBUG [MediaChannel] audio channel 1224799310 is closed
15:37:00,593 DEBUG [RtcpHandler] Could not send RTCP_BYE packet because channel is closed or disconnected.
15:37:00,593 DEBUG [ResourcesPool] Released rtp connection,pool size:10,free:9
15:37:00,593 INFO [MGCP] tx=147483703 was executed normaly
15:37:00,871 WARN [JitterBuffer] Buffer overflow!
15:37:00,891 WARN [JitterBuffer] Buffer overflow!
15:37:00,911 WARN [JitterBuffer] Buffer overflow!
15:37:00,931 WARN [JitterBuffer] Buffer overflow!
15:37:00,951 WARN [JitterBuffer] Buffer overflow!
15:37:00,971 WARN [JitterBuffer] Buffer overflow!
15:37:00,991 WARN [JitterBuffer] Buffer overflow!
15:37:01,012 WARN [JitterBuffer] Buffer overflow!
15:37:01,032 WARN [JitterBuffer] Buffer overflow!
15:37:01,052 WARN [JitterBuffer] Buffer overflow!
15:37:01,072 WARN [JitterBuffer] Buffer overflow!
15:37:01,092 WARN [JitterBuffer] Buffer overflow!
15:37:01,112 WARN [JitterBuffer] Buffer overflow!
15:37:01,131 WARN [JitterBuffer] Buffer overflow!
15:37:01,151 WARN [JitterBuffer] Buffer overflow!
15:37:01,171 WARN [JitterBuffer] Buffer overflow!
15:37:01,191 WARN [JitterBuffer] Buffer overflow!
15:37:01,212 WARN [JitterBuffer] Buffer overflow!
15:37:01,232 WARN [JitterBuffer] Buffer overflow!
15:37:01,252 WARN [JitterBuffer] Buffer overflow!
15:37:01,272 WARN [JitterBuffer] Buffer overflow!
15:37:01,291 WARN [JitterBuffer] Buffer overflow!
15:37:01,312 WARN [JitterBuffer] Buffer overflow!
15:37:01,332 WARN [JitterBuffer] Buffer overflow!
15:37:01,352 WARN [JitterBuffer] Buffer overflow!
15:37:01,372 WARN [JitterBuffer] Buffer overflow!
15:37:01,392 WARN [JitterBuffer] Buffer overflow!
15:37:01,411 WARN [JitterBuffer] Buffer overflow!
15:37:01,432 WARN [JitterBuffer] Buffer overflow!
15:37:01,452 WARN [JitterBuffer] Buffer overflow!
15:37:01,472 WARN [JitterBuffer] Buffer overflow!
15:37:01,492 WARN [JitterBuffer] Buffer overflow!
15:37:01,511 WARN [JitterBuffer] Buffer overflow!
15:37:01,531 WARN [JitterBuffer] Buffer overflow!
15:37:01,551 WARN [JitterBuffer] Buffer overflow!
15:37:01,572 WARN [JitterBuffer] Buffer overflow!
15:37:01,591 WARN [JitterBuffer] Buffer overflow!
15:37:01,612 WARN [JitterBuffer] Buffer overflow!
15:37:01,631 WARN [JitterBuffer] Buffer overflow!
15:37:01,652 WARN [JitterBuffer] Buffer overflow!
15:37:01,671 WARN [JitterBuffer] Buffer overflow!
15:37:01,692 WARN [JitterBuffer] Buffer overflow!
15:37:01,712 WARN [JitterBuffer] Buffer overflow!
15:37:01,732 WARN [JitterBuffer] Buffer overflow!
15:37:01,751 WARN [JitterBuffer] Buffer overflow!
15:37:01,771 WARN [JitterBuffer] Buffer overflow!
15:37:01,791 WARN [JitterBuffer] Buffer overflow!
15:37:01,812 WARN [JitterBuffer] Buffer overflow!
15:37:01,832 WARN [JitterBuffer] Buffer overflow!
15:37:01,852 WARN [JitterBuffer] Buffer overflow!
15:37:01,872 WARN [JitterBuffer] Buffer overflow!
15:37:01,892 WARN [JitterBuffer] Buffer overflow!
15:37:01,912 WARN [JitterBuffer] Buffer overflow!
15:37:01,931 WARN [JitterBuffer] Buffer overflow!
15:37:01,952 WARN [JitterBuffer] Buffer overflow!
15:37:01,972 WARN [JitterBuffer] Buffer overflow!
15:37:01,992 WARN [JitterBuffer] Buffer overflow!
15:37:02,011 WARN [JitterBuffer] Buffer overflow!
15:37:02,032 WARN [JitterBuffer] Buffer overflow!
15:37:02,051 WARN [JitterBuffer] Buffer overflow!

The components used to process media must be abstracted, in order to easily provide a single component for both audio and video channels.

In the UI I see:

No Answer/Rejected! Your call to +1235 was not answered.

And in the JS console, after successful response to invite I see this:
"WebRTCommCall:onRtcPeerConnectionSetRemoteDescriptionErrorEvent():error={}" WebRTComm.js:4033:0
WebRTCommCall.prototype.onRtcPeerConnectionSetRemoteDescriptionErrorEvent() WebRTComm.js:4033
WebRTCommCall.prototype.onPrivateCallConnectorRemoteSdpAnswerEvent/<()

FireFox version is 38.0.1 on a Mac

Create an RTP translator to forward traffic between two or more remote peers.
A description of a translator's behaviour can be found here and here.

Also, the RTP connection must allow the developer to change the relay type at RTP level (mixing vs translator) during runtime.

After the rework of issue #28 the jitter buffer maintains a static default size.
This value should be configurable via properties file.

@hrosa Oct 16 there was another incident with no audio at Always On.
I collected the logs, jmap and jstack traces and placed them at /opt/incident_oct16_2015

Please investigate and update about this.

Reduce to DEBUG the logging threshold for the following type of messages:

WARN Channel No protocol handler was found to process an incoming packet. Packet will be dropped.

Recent performance tests showed a CPU leak in the media server process.
With help from a profiler, I noticed some tasks keep executing in the Scheduler, even after the performance test is over.

Implement a factory to generate SDP offers and answers, helping to eliminate boilerplate code

Implement a Selective Forwarding Unit (SFU) capable of receiving multiple media streams and then decide which of these media streams should be sent to which participants.

A description about SFU topology can be found here:
https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-07#section-3.7

The RTP specification also makes proper distinction of relay types at RTP level (mixer vs translator):
http://tools.ietf.org/html/rfc3550#section-7

If video is enabled (m=video in SDP) when calling one of these demos, it fails. Probably it should be able to fallback to audio only.

Currently the Audio Player is using blocking IO which can result in bad performance of the MS.
The Audio Player task is handled by the Scheduler where NO blocking operations should take place.

The ResourcesPool must be responsible for ensuring the quality of its objects.
Whenever an object is released back into the pool, its resources must be properly closed and its internal state must be reset.

Currently, the Media Server relies on a JBoss microcontainer to deploy and configure a set of beans, necessary for the functioning of the Media Server. As such, the configuration of the Media Server is limited and non-extensible and the initialization of the objects happen behind the scenes and relies heavily on reflection.

This approach prevents some suitable classes from adopting patterns like Factory or Singleton and causes these objects references to be passed via setter or constructor, sometimes resulting in high number of references.

We should implement a bootstrapping mechanism similar to RestComm, where a Bootstrapper service would read from a well-structured configuration file and then initialize the necessary beans. We could also introduce dependency injection to help manage all references to required objects.

The only kind of endpoint that makes use of media a group is the IRV endpoint.
Having all endpoints owning a media group and initializing media resources (player, recorder, signal generator, signal detector) is a waste.

Currently the IceAgent uses a ConnectivityCheckServer, which spans a new Thread, to handle IO operations for the ICE candidate selection process.

A better approach is to have the IceAgent relying on the UDP Manager to open the channels for each candidate and attach a StunHandler to them. This will greatly reduce the number of spanned Threads and will consolidate the design of the Media Server

As a result the DTLS negotiation fails

When do recording at heavy load, the mms server got follow exception :

java.lang.NullPointerException
    at org.mobicents.media.server.impl.resource.audio.AudioRecorderImpl.writeToWaveFile(AudioRecorderImpl.java:302)
    at org.mobicents.media.server.impl.resource.audio.AudioRecorderImpl.deactivate(AudioRecorderImpl.java:185)
    at org.mobicents.media.server.mgcp.pkg.au.PlayRecord.terminateRecordPhase(PlayRecord.java:317)
    at org.mobicents.media.server.mgcp.pkg.au.PlayRecord.terminate(PlayRecord.java:397)
    at org.mobicents.media.server.mgcp.pkg.au.PlayRecord.cancel(PlayRecord.java:218)
    at org.mobicents.media.server.mgcp.controller.Request.cancel(Request.java:132)
    at org.mobicents.media.server.mgcp.tx.cmd.NotificationRequestCmd$Request.perform(NotificationRequestCmd.java:120)
    at org.mobicents.media.server.scheduler.Task.run(Task.java:122)
    at org.mobicents.media.server.scheduler.Scheduler$WorkerThread.run(Scheduler.java:420)

And I tried making follow changes in AudioRecorderImpl.java solved it:

private void writeToWaveFile() throws IOException {
        Endpoint ep = getEndpoint();
        String epName = ep == null ? null : ep.getLocalName();
        if (epName == null)
            logger.info("!!!!!!!!!! Writting to file......................");
        else
            logger.info("(" + epName
                    + ") !!!!!!!!!! Writting to file......................");
        ...

Currently, the Media Server only supports SHA-256 encryption.
This breaks interoperability with clients that want to use a different hash function.

Currently Mobicents MS only supports ICE-lite which can add a significant delay to the Call setup process. To speed up this process, trickle-ICE should be implemented.

The specification for trickle-ice can be found here:
https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-02

The maven dependency for org.mobicents.external.jsr309:mscontrol:1.0 is broken, as it is not on maven central. Perhaps updating the correct repository where it can be found or redeploying to maven will help?

The UDP manager must use the new scheduling mechanism which implements the Scheduler interface, instead of accessing directly to an instance of ScheduledExecutorService.

Since the ScheduledExecutorService manages a ThreadPool whose capacity is related to the system's capacity, it is recommended to have only one instance in the MS. For this reason, the Scheduler should be used instead because it's a singleton.

MMS failed , there were a lot of MGCP time outs at Restcomm side.
Logs can be found at Always-On folder: /opt/incident_Oct21

Hi,

i'm using mobicents RTP to implements a media server and SBC monitor, by setting up a call and sending and receiving RTP. Unfortunately, whenever the call is stopped and restarted there is a Thread leak, memory leak and slowly increasing CPU usage, to the point that eventually the app crashes.

I've based it on the RTPChannelTest class.

the call setup is as follows:

    sendSource = new Sine(scheduler);
    sendSource.setFrequency(100);        

    // set peer on sending channel. receiving channel has already been bound
    getSendChannel().setPeer(new InetSocketAddress(mediaServerAddress, sendRemotePort));

    getSendChannel().setFormatMap(AVProfile.audio);
    getRecvChannel().setFormatMap(AVProfile.audio);

    // setup an audio component to receive the input
    sendComponent=new AudioComponent(1);
    sendComponent.addInput(sendSource.getAudioInput());
    sendComponent.updateMode(true,true);

    // setup an audio mixer to receive the input; mix the send component and send channel
    sendAudioMixer=new AudioMixer(scheduler);
    sendAudioMixer.addComponent(sendComponent);
    sendAudioMixer.addComponent(getSendChannel().getAudioComponent());

and the tear down:

        sendSource.deactivate();
        sendChannel.close();
        recvChannel.close();
        sendAudioMixer.stop();
        udpManager.stop();
        scheduler.stop();

the problem appears to be in the Scheduler class, specifically the CriticalWorkerThread and the Worker thread where they remain in the WAITING state on the take statement (line 413) in

                try
                {
                    current=waitingTasks.take();
                }
                catch(Exception ex)
                {

                }                   

the Scheduler.stop() method only sets the 'active' boolean for the threads which can never be tested while the threads are in the WAITING state.

What is the correct way to stop the scheduler to prevent this thread leak?

I've thought of adding something to interrupt the threads, but there is an empty catch block which would just swallow the resultant interrupt.

Any guidance would be much appreciated as this is it makes my head hurt trying to get to grips with this code and how to fix my app or modify the code.

thanks, Mitchell

The RTP and RTCP channels contained in an RTP connection should be wrapped in a proper Media Channel class. This measure should clean up code and allow easier management of the lifecycle of an RTP connection.

Clean warnings with simple solution and perform code formatting/cleanup when possible.

Using Jitsi 2.5.5313 and the following codecs:

1. ILBC
2. PCMU
3. PCMA
4. OPUS

when calling 1234 there is no audio but a noise.

Even though opus is not supported by the MMS, seems that codec opus causes that noise because if opus is disabled audio is ok.

i want a audio mixer for all incoming calls to merge into single audio stream for conference purpose ?
my application is in sip.js