SipPlugin read rfc2833 dtmf and convert to sip info event

[ywmoyue]

Implement the features proposed by jkmchinese from https://janus.discourse.group/t/audiobridge-with-sip-participants/131/7

this PR get rfc2833 data from rtp stream and assemble a sip-info event push to user

[januscla]

Thanks for your contribution, @ywmoyue! Please make sure you sign our CLA, as it's a required step before we can merge this.

[ywmoyue]

Thanks for your contribution, @ywmoyue! Please make sure you sign our CLA, as it's a required step before we can merge this.

I have signed

[lminiero]

Apologies for the late feedback. I've added some notes inline.

[ywmoyue]

@lminiero Thank you very much for your review. I will revise and self-test and submit the code again next week.

[ywmoyue]

@lminiero I have accepted your comments and made the changes, can you please review this PR again?

[lminiero]

Added a few more comments inline.

[ywmoyue]

@lminiero Thanks for the review again. I have accepted your comments and made the changes.

[lminiero]

Thanks! I'll see if I can test this somehow.

[lminiero]

Just tested this and it seems to be working nicely, thanks! I'm just reporting a couple of warnings my compiler gave: as soon as you can address those, this is good to merge for me.

[ywmoyue]

I fixed the two errors, can you please check again

[lminiero]

Thanks, merging then! 👍

[ycherniavskyi]

@ywmoyue, I'm curious about the choice to set a hardcoded payload type of 101 for the telephone-event RTP payload format. According to RFC2833, this type is typically assigned dynamically. Could you elucidate the reasons for opting for a hardcoded value instead of retrieving the actual payload type dynamically from the SDP?

My concern stems from potential compatibility issues, such as with SIP calls initiated by the Janus SIP plugin. It appears that the WebRTC library used by browsers uses different (and currently hardcoded) payload types for telephone-event, which could lead to functional mismatches.

[ywmoyue]

@ycherniavskyi Yes, you are right to concern

The reason why I use 101 as the telephone-event payload is that the terminals I tested here use 101 as the telephone-event payload by default, except for webrtc, including yealink phone, linphone, real android phone with VOLTE, and others soft phone

The correct way is indeed to get the telephone-event payload value from sdp, I will see if I can submit a PR to fix this later