SIP 415 Unsupported Media Type: what it means and how to fix it

Short answer: SIP 415 Unsupported Media Type means the server rejected the request because the message body is in a format it does not accept for that method. It is not a codec mismatch, which produces a 488. The most common cause is an unexpected Content-Type. Read the response's Accept header, which lists the accepted formats.

How Monitor treats SIP 415

The reading depends on what should answer the number, which is the question 2N5 answers when it adds each circuit. These are the rules the product applies today, generated from the same function that judges every test call.

What should answer the number	Reading
A greeting or recorded message (the IVR)	Down
A test tone or echo service	Down
Other: it may ring or be answered	Down

What Monitor records for an IVR: The provider refused the call (SIP 415).

A call read as Down alerts nobody on its own: it is repeated 3 times, every 2 minutes, and only 4 failures in a row open an incident, with each call's SIP code and Q.850 cause as evidence for the carrier. At the default pace, every circuit is tested every 15 minutes.

If the carrier returns SIP 415 when 2N5's calling account registers, before any call, the test is monitoring blind: it is a problem on 2N5's side, it does not count against the circuit and it does not alert the customer.

What does SIP 415 mean in practice?

Under RFC 3261, SIP 415 Unsupported Media Type indicates that the server refuses to service the request because the message body is in a format it does not support for the requested method. The server should return the list of accepted formats in the Accept, Accept-Encoding or Accept-Language headers, depending on the problem.

On trunks, the SIP 415 error is rare on an ordinary call, because almost every INVITE carries only application/sdp. It shows up when some device adds other content, such as a multipart body with signaling data from the phone network or a compressed body, or when in-call messages, such as INFO for DTMF, use a type the other side does not accept. For codec incompatibility, the correct code is SIP 488.

Common causes in Brazil

• A PBX or SBC sending an INVITE with a multipart/mixed body (SDP plus phone-network signaling data) to a carrier that only accepts SDP.
• DTMF sent by SIP INFO with application/dtmf-relay or application/dtmf, rejected by the other side while navigating an IVR.
• A compressed body (Content-Encoding: gzip) that the destination server cannot open.
• A Content-Type header missing or misspelled after a customization in Asterisk, Issabel, FreePBX or 3CX.
• An interconnection gateway configured for SIP-I or SIP-T talking to an ordinary SIP trunk.

How to diagnose it

1. Capture with sngrep port 5060 and check which method got the 415 (INVITE, INFO, MESSAGE) and the Content-Type that was sent.
2. Read the Accept, Accept-Encoding and Accept-Language headers in the response to learn what the server accepts.
3. On Asterisk or FreePBX, turn on pjsip set logger on (or sip set debug on with chan_sip) and check the trunk’s DTMF mode. In PJSIP, prefer dtmf_mode=rfc4733.
4. If the INVITE carries a multipart body, review the SBC or gateway that adds it and turn off the inclusion of phone-network signaling data for that trunk.
5. On 3CX, enable “Verbose logging” and check the trunk’s DTMF mode and advanced parameters.
6. Place a test call to an IVR and press options to confirm the digits arrive without a 415.

What to send the carrier

• Date and time of the occurrences, with the time zone.
• Calling number (A) and called number (B).
• The Call-ID of the call and the method that got the 415.
• The full response line and the Accept headers received.
• The Content-Type sent and how many attempts failed.
• The pcap of the capture, when available.

Frequently asked questions

Is a 415 the same thing as an incompatible codec?

No. Codec incompatibility is handled inside the SDP and usually produces SIP 488 Not Acceptable Here. The 415 is about the type of the whole body, given in the Content-Type header, such as application/sdp, multipart/mixed or application/dtmf-relay. If the server does not accept that type for the method used, it answers 415 without ever getting to codec negotiation.

Why do I get a 415 mid-call when pressing keys in an IVR?

When the PBX sends DTMF digits as SIP INFO messages, the body goes out with a type such as application/dtmf-relay. If the other side does not accept that type, it answers the INFO with a 415 and the digit is lost, although the call continues. Switch DTMF to RFC 4733 (events in the RTP), which is the standard carriers accept most widely.