Mixer drop participants

[GoogleCodeExporter]

When multiple participants are in a cnf endpoint some time in to the 
conversation the endpoint will stop mixing the audio coming from some or all of 
the participants.

The following is what MMS reports right before mixing breaks.

19:01:40,378 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,378 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,379 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,398 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,398 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,418 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,418 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,438 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,438 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,457 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,457 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,477 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,478 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,498 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,498 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,518 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,518 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,538 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,538 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
Convert: A
19:01:40,558 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
19:01:40,558 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
19:01:40,577 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
drop packet: dead line=9698560, packet time=9697920, seq=-4903, payload 
length=160, format=0 AudioFormat[pcmu,8000,8,mono]
drop packet: dead line=9698560, packet time=9698080, seq=-4902, payload 
length=160, format=0 AudioFormat[pcmu,8000,8,mono]
drop packet: dead line=9698560, packet time=9698240, seq=-4901, payload 
length=160, format=0 AudioFormat[pcmu,8000,8,mono]
drop packet: dead line=9698560, packet time=9698400, seq=-4900, payload 
length=160, format=0 AudioFormat[pcmu,8000,8,mono]

Earlier in the logs the format was changed to pcma (attached are the complete 
logs for MSS + MMS). The problem seems to be that the audio format change on an 
ongoing conference will break the mixer. For now I have disable all codecs 
except pcmu on the instance to see if that prevents the audio format from 
changing.

Tom

Original issue reported on code.google.com by quintana...@gmail.com on 13 Jul 2012 at 7:30

Attachments:

• restcomm-New-Always-On-incident_Jul13_2012_19_25_tar.gz

[GoogleCodeExporter]

Update: Disabling codecs other than pcmu seems to have temporarily re-solved 
the problem until a more permanent solution can be devised.

Original comment by quintana...@gmail.com on 13 Jul 2012 at 7:53

[GoogleCodeExporter]

Actually, after further testing everything was going well and I got the 
following messages right before mixing broke. Hanging up and calling back in 
solves the problem for the participant with the bad connection.

20:02:32,823 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,844 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,844 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,864 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,864 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,883 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,883 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,904 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,904 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,924 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,924 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,944 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,944 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,964 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,964 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:32,984 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:32,984 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:33,003 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:33,003 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:33,024 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:33,024 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:33,044 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:33,044 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:33,064 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:33,064 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
Convert: 6
20:02:33,083 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:33,083 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:33,104 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:39,044 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:39,064 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:39,064 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:39,084 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:39,084 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:39,148 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:39,149 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
Convert: 8
20:02:39,149 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]
20:02:39,149 INFO  [JitterBuffer] Format has been changed: 101 
AudioFormat[telephone-event,8000,mono]
20:02:39,150 INFO  [JitterBuffer] Format has been changed: 0 
AudioFormat[pcmu,8000,8,mono]

Original comment by quintana...@gmail.com on 13 Jul 2012 at 8:08

[GoogleCodeExporter]

Hi
drop packet does not brakes the connections.it only shows that sequence has 
been changed in receiving stream.when this happens jitter buffer drops up to 5 
packets and starts working with new sequences.
What do you mean by mixing breaks?does all participants stopscworking,or single 
one?does other participants hears him,do he hears others> do you see packets 
sent/received from his ip in wireshark?

Original comment by oifa.yul...@gmail.com on 15 Jul 2012 at 1:57

[GoogleCodeExporter]

I understand that dropped packets does not break the connection but when
the audio format changes mixing stops working and the outcome is
underterministic. Some times the participant can hear but not speak
sometimes neither. I will re-create and attach capture tomorrow.

Original comment by quintana...@gmail.com on 15 Jul 2012 at 2:03

[GoogleCodeExporter]

Original comment by oifa.yul...@gmail.com on 21 Jul 2012 at 10:29

• Added labels: Version-2.4.0

[GoogleCodeExporter]

Original comment by oifa.yul...@gmail.com on 21 Jul 2012 at 10:29

[GoogleCodeExporter]

Please use latest trunk and provide the following information if the problem 
still exists.
1) Time from crcx when the problem begins approximately.Is it static time or 
not.
2) Direction ( does client continues to hear others , does others hear him ).
3) Wireshark log on client side , whether he continues to receive rtp packets , 
whether he receives icmp messages of any kind.
4) Wireshark log on server side , whether the messages are sent from mms / 
whether the messages are received from client , whether any king of icmp 
messages are received by mms.

If the problem does not exists anymore please post update so i will close a 
ticket

Original comment by oifa.yul...@gmail.com on 21 Jul 2012 at 10:52

[GoogleCodeExporter]

Thanks Yulian we will do

Original comment by jean.deruelle on 22 Jul 2012 at 9:17

[GoogleCodeExporter]

Thanks Yulian we will do

Original comment by jean.deruelle on 22 Jul 2012 at 9:17

[GoogleCodeExporter]

Closed by revision  883e9ba6a7b2

Original comment by oifa.yul...@gmail.com on 24 Jul 2012 at 8:27

• Changed state: Fixed