There are times where you check the RTP streams in your VoIP capture and everything looks sane, although one or more parties in the call reported no audio.
Those times, in particular when G.711 is in use, can be made a little less frustrating by looking at the RTP payload.
In fact, it's possible that one party is just sending silence. With G.711 silence has its own coding, and it's easy to spot:
a-law: silence is either a payload entirely populated with 0x55 or 0xD5 (depending on the sign applied).
u-law: silence is a payload entirely populated with 0xFF.
Hello Giacomo,
ReplyDeleteI'm facing the seame issue.
I have no signs of CN negotiation in my SDP.
Where did you find the official explanation thaht in a-law silence is either a payload entirely populated with 0x55 or 0xD5. I tried to read many RFC, but I might to much smartless :)
Thanks,
Ah, that's a very good question. I think you can find your answer here: http://www.itu.int/rec/T-REC-G.711/
ReplyDeletebut you need to consider a subtle detail:
"The input signals to an A-law decoder will normally include even bit inversion as applied in accordance with [...]"
So it's easier to see it this way:
0x55 == 0b01010101
0b01010101 == 0b00000000 with even bits inverted.
0xD5 == 0b11010101
which is the same as above, but with the sign bit (leftmost) set to 1.
I hope this is a better and more useful explanation.
Cheers,
Giaccomo
I am having this same problem. Have you found any solutions?
ReplyDeleteI will thank you very much any recommendations you can give me.
Sorry for my English.
Sincerely, Diego
What about other silence RTP packets for G272 or G723 or G729?
ReplyDeleteI have learnt that silence packets may be 0x55,0x56,0xD5,0xD6 for G711 by analyzing recorded pcap for g711 codec, but any information the rtp content for the other codecs