Error parsing/validating SDP body: Missing SDP rtpmap for dynamic payload type (PJMEDIA_SDP_EMISSINGRTPMAP)

[joni]

Hello everyone,

we have a problem that a specific company is unable to call us. Our Asterisk sends a “400 Bad Request” as a response to the invite packet. We can call the other company without a problem.
In the Asterisk console the following error is printed:

ERROR[5186]: pjproject: <?>:                   sip_inv.c .Error parsing/validating SDP body: Missing SDP rtpmap for dynamic payload type (PJMEDIA_SDP_EMISSINGRTPMAP)

So I did a tcpdump of the incoming call and I am not quite sure if the media description and the media attributes in the session description protocol are correct. As of my understanding the media attribute for the value 101 is missing in the packet. Could this be the reason why Asterisk is not accepting this request?
This is the raw content of the packet:

m=audio 21186 RTP/AVP 8 0 2 113 112 114 15 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:112 G726-16/8000
a=rtpmap:114 G726-40/8000
a=rtpmap:15 G728/8000
a=ptime:20
a=maxptime:20
a=sendrecv

This is a screenshot of the packet from Wireshark.

I have tested it with Asterisk 18 LTS und Asterisk 20 LTS. Is it an Asterisk problem or a problem of the caller? Why is Asterisk not accepting it?

I am using FreePBX but I think it is more Asterisk related. Sorry if I am wrong and posted it on the wrong forum.

[david551]

You have basically already diagnosed the problem. The messages is saying that they have offered you media type 101, which has no intrinsic meaning, without explicitly stating what it means. It is a problem with the caller.

(It’s probably telephone events, i.e. RFC 4733, but it could be anything.)

[joni]

Thank you for your fast response. I wanted to be sure that I am not missing anything. Is there a workaround that asterisk just will ignore the missing part and allows the incoming call although it is more of a problem from the callers system? I guess the other company will tell me that they have no problem with other calls.

[jcolp]

There’s nothing in Asterisk configuration to disable this, it even happens before Asterisk has any idea such a SIP INVITE has been received. It’s down in PJSIP validation stuff. You could try looking through the PJSIP code and seeing if you could change the code or there’s some other mechanism to disable it, I don’t know if there is.

[joni]

I see this problem has more to do with the PJSIP library than with Asterisk. After reading through the RFC 8866 it looks like PJSIP is handling the packet correctly.
In section 6.6 it says:

An example of a dynamic payload type is 16-bit linear encoded stereo audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP payload type 98 for this stream, additional information is required to decode it:

m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2

RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP.

Because the media format description value 101 is a dynamic RTP/AVP payload it needs to be defined in the rtpmap. Please correct me if I am misinterpret it.
My skills in C programming are very limited to create a workaround by myself. Maybe I will create an issue on github for this. It seems that most other SIP stacks seems to ignore it and allow the packet anyway.

[david551]

I think your interpretation is correct.

There is an internet principle that you should be correct in what you send and tolerant in what you accept, and, as anything can be ignored, it would sound sensible to me for PJPROJECT to generate a warning then treat it as though it had not been offered. On the other hand, there is an argument that this doesn’t encourage senders to play their part.

[jcolp]

PJSIP tends to take the more strict approach, because being forgiving can mean you have to handle more off-nominal scenarios which can cause further issues and complicates the code.