CODEWITHSUNDEEP
siptelephonysdp
Craig
Craig

Reputation: 1

SIP SDP Negotiation - How to not support RFC-2833 Telephony events

We have circumstances where we wish to use DTMF tones instead of RFC2833 telephony events to detect DTMF digits. We are attempting to avoid double DTMF digit detection by responding to the SIP Invite (that includes support for telephony events in its SDP) with a 200 OK that does not support telephony events.

e.g.

Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:[email protected]:5060 SIP/2.0
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): sphericall 24706 24707 IN IP4 172.23.20.122
            Session Name (s): -
            Connection Information (c): IN IP4 172.23.31.2
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 19708 RTP/AVP 8 0 18 101
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:0 PCMU/8000
            Media Attribute (a): rtpmap:18 G729/8000
            Media Attribute (a): fmtp:18 annexb=no
            Media Attribute (a): rtpmap:101 telephone-event/8000
            Media Attribute (a): fmtp:101 0-16

Which we respond to with;

Session Initiation Protocol (200)
    Status-Line: SIP/2.0 200 OK
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 3720425649 3720425650 IN IP4 0.0.0.0
            Session Name (s): pjmedia
            Bandwidth Information (b): AS:84
            Time Description, active time (t): 0 0
            Session Attribute (a): X-nat:0
            Media Description, name and address (m): audio 20004 RTP/AVP 8
            Connection Information (c): IN IP4 172.23.20.127
            Bandwidth Information (b): TIAS:64000
            Media Attribute (a): sendrecv
            Media Attribute (a): rtpmap:8 PCMA/8000

However, even though we have not included support for telephony events in our response we still received them. Is there something we are doing wrong or can we not stop the server from sending them with the SDP negotiation.

Upvotes: 0

Views: 2045

Answers (1)

Bucq
Bucq

Reputation: 1021

I don't think you are doing anything wrong.

The SDP answer contains the codecs the UA is willing/able to process. Your SDP answer contains only PCMA audio and the peer UA (or SIP server) should honor that. The fact that it doesn't means it's poorly implemented (imho).

Most SIP servers have a property to specify which kind of DTMF signalling has to be used (RFC 2833/4733, SIP INFO, in-band audio). I think you should look for this property if you want to control the type of DTMF signalling used.

Upvotes: 1

Related Questions