INVITE SDP randomly rejected: Invalid SDP attributes (PJMEDIA_SDP_EINATTR)

Hi everyone,

I’m running into an issue where Asterisk 16.0.1 will randomly reject SIP INVITE messages, claiming that the SDP contains invalid attributes. I say ‘randomly’ since my SIP clients always send INVITE messages with the same structure, but Asterisk only encounters problems parsing the SDP some of the time.

ERROR[29539]: pjproject:0 <?>: sip_inv.c .Error parsing/validating SDP body: Invalid SDP attributes (PJMEDIA_SDP_EINATTR)

This problem occurs about 10% of the time when using the Speex codec, but I have also seen it happen with PCMA, albeit far less often. Asterisk responds with “400 Bad Request”. I have verified in Wireshark that the SIP/SDP of accepted and rejected INVITE messages are in fact identical (apart from dynamic elements such as the URI and ports, naturally). Speex SDP is attached. Could race conditions be at play? Is this a known issue?

SDP as seen in Wireshark:
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): Test 123 123 IN IP4 1.0.10.3
Session Name (s): CaptureME
Connection Information ©: IN IP4 1.0.10.3
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 49835 RTP/AVP 110
Media Attribute (a): rtpmap:110 speex/8000
Media Attribute (a): fmtp:110 mode=“3,any”
Media Attribute (a): sendrecv

I’m currently trying to find a way to reliably reproduce the issue. My program contains multiple SIP endpoints that attempt to call a ConfBridge conference at startup. The more clients I spin up, the more likely I am to encounter the issue.

Thanks in advance for you help!

Please provide the raw SDP, not wireshark’s interpretation of it. Also please provide the Asterisk debug log in sufficient detail to show which line is being rejected. (assuming chan_pjsip logs in similar detail to chan_sip).

Hi David,

Thanks for responding. Please find below the SDP for both a successful and a rejected INVITE. Note I removed the fmtp line after it made no difference to the behaviour.

Successful SDP:
v=0
o=Test 123 123 IN IP4 1.0.10.3
s=CaptureME
c=IN IP4 1.0.10.3
t=0 0
m=audio 51125 RTP/AVP 110
a=rtpmap:110 speex/8000
a=sendrecv

Rejected SDP:
v=0
o=Test 123 123 IN IP4 1.0.10.3
s=CaptureME
c=IN IP4 1.0.10.3
t=0 0
m=audio 48061 RTP/AVP 110
a=rtpmap:110 speex/8000
a=sendrecv

Unfortunately, running Asterisk with verbose logging ‘asterisk -vvvvvvr’, provides no extra information with the error message than what I posted initially - that is, it doesn’t specify a line number or why is was rejected (same goes for /var/log/asterisk/messages).

I don’t seem to encounter the problem if I restart Asterisk before running my program, so perhaps Asterisk gets into some state during my program’s subsequent startups, during which time modules and config (pjsip, dialplan etc) are being reloaded.

No luck yet in making it fail reliably.

Thanks in advance for your help!

I think you need both pjsip debug and debug level logging to see the detailed analysis. However I’ve only dealt with this sort of thing with chan_sip, so am not completely sure how much logging is available.

Hi David,

With ‘pjsip set logger on’, the following was all the information it gave me for one rejected SDP where my client was dialing into conference extension ‘9’ and establishing the media stream as ‘sendonly’ speex (though it happens with ‘sendrecv’ too). The line ‘a=fmtp:110 vbr=on;vbr=vad’ was just there for testing, but I confirmed it wasn’t affecting the rejection behaviour.

The logger output doesn’t seem to specify any more information unfortunately.

I also tried ‘logger set level DEBUG’ and ‘logger set level VERBOSE’ for the CLI, but that didn’t seem to have any effect…

<— Received SIP request (624 bytes) from UDP:1.0.10.3:35899 —>
INVITE sip:9@1.0.10.3 SIP/2.0
Via: SIP/2.0/UDP 1.0.10.3:35899;rport
From: sip:Ch30@1.0.10.3;tag=duDtdgNWUWggWG6z
To: sip:9@1.0.10.3
CSeq: 21 INVITE
Call-ID: 8KHzUiNNtQU7zzW6
Max-Forwards: 70
Supported: outbound
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
Contact: sip:Ch30@1.0.10.3:35899
User-Agent: Test/1.0
Content-Type: application/sdp
Content-Length: 167

v=0
o=Test 123 123 IN IP4 1.0.10.3
s=CaptureME
c=IN IP4 1.0.10.3
t=0 0
m=audio 46995 RTP/AVP 110
a=rtpmap:110 speex/8000
a=fmtp:110 vbr=on;vbr=vad
a=sendonly
[Aug 7 13:02:10] ERROR[27675]: pjproject:0 <?>: sip_inv.c .Error parsing/validating SDP body: Invalid SDP attributes (PJMEDIA_SDP_EINATTR)
<— Transmitting SIP response (330 bytes) to UDP:1.0.10.3:35899 —>
SIP/2.0 400 Bad Request
Via: SIP/2.0/UDP 1.0.10.3:35899;rport=35899;received=1.0.10.3
Call-ID: 8KHzUiNNtQU7zzW6
From: sip:Ch30@1.0.10.3;tag=duDtdgNWUWggWG6z
To: sip:9@1.0.10.3
CSeq: 21 INVITE
Warning: 399 SIP “Invalid SDP attributes (PJMEDIA_SDP_EINATTR)”
Server: Asterisk PBX 16.0.1
Content-Length: 0

You can also enable debugging directly from pjproject that could prove helpful. For instance, add something like the following to the pjproject.conf file (if you don’t have that file then create it wherever your other Asterisk conf files are located):

[startup]
type=startup
log_level=4

After restarting you should see more log data. It should output the line/column in the offending SDP.

Also if you are familiar with SIPp you might be able to use that to create a scenario that replicates the problem for faster testing.

Hi kharwell,

Thanks for your advice. I updated my pjproject.conf file and discovered that my version of Asterisk 16 was compiled with a limited pjproject logging level, as shown by the error message below.

[Aug 8 15:36:16] WARNING[11437]: res_pjproject.c:529 load_module: Asterisk built or linked with pjproject PJ_LOG_MAX_LEVEL=3 which is too low for startup level: 4.

I’m currently rebuilding Asterisk with PJ_LOG_MAX_LEVEL=4, which should hopefully provide the extra ‘DEBUG’ level logging info I need to solve this issue. I’ll let you know once I have things up and running!

Cheers.

I’m having trouble finding where PJ_LOG_MAX_LEVEL=3 is defined in Asterisk/pjproject.

Initially I thought it was part of Asterisk options.h, but now it looks to be part of pjproject. The change log talks of how it was reduced from 6 to 2 to deal with some overwhelming logging from pjsua.

Would appreciate if anyone can point me in the right direction.

Thanks for you help!