A question to RTP, comfort noise and how Asterisk reacts

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

Asterisk can packet to packet bridge RTP, in which case I think CN will be passed through. This requires that direct media not be possible, but the media formats are compatible and there is no need to monitor them.

I believe ABE support should be obtained from the vendor. Open source support should be on the Asterisk Support forum of this board.

thanks david,

does this mean that ABE acts faulty too? it should not restart the RTP streams?

I will check with my vendor to have him open a case with digium.

dan

after reading again rfc3389, what I wonder is if it is normal that CN packets seem to “restart” or “split” the RTP stream with the codec payload. is that behaviour expected? documented somewhere?

see, a short conversation though provider A, gets me 2 RTP streams. one up and one down. that provider A does not send me any CN packets. nothing negotiated during SIP/SDP… as expected…

the same (same destination, same duration) short conversation through provider B, gets me 6 RTP streams. again, SIP/SDP does not say anything about payload 13…
so I get a bunch of RTP streams. one up and 5 down. in that example, I see 2 CN packets which count as RTP stream in wireshark analysis. so I have one RTP stream coming down, then a CN packet, then another RTP stream, yet another CN packet and the last RTP stream.

is that normal?

dan