first of all, I know that Asterisk is not supporting fully comfort noise. but my question has a bit to do with this too.
(I am also not an Asterisk nor a network specialist (anymore))
situation:
- I have an box that runs ABE (Asterisk Business Edition C.3-bier-20110722).
- on that box are a couple of snom870 phones attached.
- on the provider side, it connects to an asterisk 1.6 box with a SIP trunk setup.
what I am interested in is why the ABE box is acting the way it does…
now the problem (inbound = provider to ABE, outbound = ABE to provider):
inbound RTP streams have a bad sound quality… meaning that every few seconds, there is a short audio interruption that leads to people not understanding words during a conversation… verrry annoying…
so I started to search for the reasons… and found it has to do with a flaky (?) comfort noise implementation?
on a call, SIP sets up a connection that should not use comfort noise. I verified this in the traces of the SIP/SDP packets during invite negotiation.
yet, I noticed on the same traces that the inbound RTP stream contains regular comfort noise packets (CN, payload 13). the interruptions I mention above are mostly synchronous with the appearances of those packets. the CN packets arrive roughly every 11 seconds.
now, I know that Asterisk 1.6 should not send those packets at all. I guess this is a bug.
on the other hand, ABE seems to have a problem too, and that puzzles me.
based on SIP negotiations it is clear that the RTP streams should not contain CN packets. thus my conclusion is that if there would such packets come along anyway, ABE should just silently ignore them.
instead what happens is that ABE is starting a new RTP stream each time such a CN packet arrives. this is leading to those audio interruptions.
let’s say I have a short phone call (ca. 20 seconds) with exactly one such CN packet come along. what I see in the wireshark trace is one outbound RTP stream, but 3 inbound RTP streams (one for the audio data before the CN packet, the second for the CN packet and the third for the audio data after the CN packet until I hangup). though sometimes, a CN packet will not trigger a split of the audio RTP stream.
now the questions:
is this normal behaviour?
should this actually happen at all if the session was negotiated without comfort noise in the beginning?
is this eventually a bug in ABE?
can this be fixed in ABE (like telling ABE to ignore CN packets…)?
I might not understand the whole story. at the end, I only learnt about this all only yesterday when I started reading such light stuff like RFC3389. I am not a network supporter anymore since years. so I draw from very old experience…
thanks for any hints, teaching lesson or pointers.
dan