How to support DTMF out of band?

[rwil02]

Hi Aaron.

I'm looking at having to support DTMF via OOB using SIPSorcery.
So far pretty much everything in the service providers end has seemed to change for this project.

I've got little idea where to start, but it looks like I need to check the invite for
a=rtpmap:101 telephone-event/8000

And then connect a port to an RTPChannel to handle it if it's present?

And from reading through the RTPChannel and RTPPacket code, the RTPPacket should be fine, but RTPChannel assumes it is either a single packet audio frame, or a video frame, so I would need to implement a DTMF RTPChannel?

[sipsorcery]

I've never come across out of band DTMF in the will I'm sure it's out there given there are RFC's for it (RFC2733 and RFC4733) but I suspect it might be restricted to inter-carrier networks. Had a brain fade when I originally wrote that, RFC2833 is the default DTMF mechanism for a lot of soft phones and media servers.

The best approach is to use DTMF via SIP Info. That mechanism puts DTMF events into SIP INFO requests and means there's no extraction from audio RTP packets required.

If you do need to go down the out of band path then there's nothing specifically useful in the sipsorcery code base as I've never worked with it.

[rwil02]

Lightning fast :)
I was just looking at this:
https://www.voip-info.org/wiki/view/SIP+DTMF+Signalling

Which implies to me that "telephone-event" might actually arrive in the same RTP Channel and so it might be a matter of replacing ProcessRTPPackets?

If I pull https://github.com/sipsorcery/sipsorcery/tree/master/sipsorcery-core will that match 1.5.6?
I might go through and add a pile of logging in there and test if the DTMF packets are coming through.

[rwil02]

Just to say I "think" I've managed to submit a change to you that allows you to intercept an RTP Packet and choose to handle it first (such as for handling DTMF)

Change was in RTPChannel.cs which I've attached, just in case.

RTPChannel.zip

[sipsorcery]

You should hook up the RTPChannel.OnFrameReady event. There's no need for your additional ProcessRTPPacketsCustom property.

The additional advantage of using the OnFrameReady event is that you will get full RTP frames rather than partial ones. If your DTMF was spread across multiple RTP packets you'd need the full frame to be able to extract them.

[rwil02]

Yeah, that got it.
Looks like for End/Reserved/Volume I had to reverse the bit order (IsLittleEndian = true).
Does that sound right to you?

[rwil02]

Only other thing I've got is a Before Send Request/Response event added to SIP Transaction because the server I'm talking to isn't happy with a blank "user" in the contact field for some reason.
SIPTransaction.zip

I couldn't find any other way to gain access to the "OK" response.
I've tried to attach it here.

[sipsorcery]

RTP events are now available. An example program and explanatory article are also available.