Incorrect processing of ssrc attribute from SDP

[MGorshkova]

Describe the bug

SDP of external SIP client contains the attribute ssrc:

v=0
o=123456 3 3 IN IP4 192.168.100.22
s=pjmedia
c=IN IP4 192.168.100.22
t=0 0
a=rtpmap:8 PCMA/8000
m=audio 5070 RTP/AVP 8 101
a=sendrecv
a=ssrc:900323067
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Error occurs during the processing of ssrc.
Call from pjsua to this SIP client is not successfull.

Steps to reproduce

1. Run PJSUA client
2. Call to external SIP client which respons SPD with ssrc attribute
3. Call terminated with the error

14:23:37.068 pjsua_media.c ......pjmedia_stream_info_from_sdp() failed for call_id 0 media 0: Invalid SDP ssrc attribute (PJMEDIA_SDP_EINSSRC)

PJSIP version

2.17

Context

PJSUA is built on Windows 10

Log, call stack, etc

--end msg--
14:23:37.040           pjsua_core.c  .RX 750 bytes Response msg 200/INVITE/cseq=30252 (rdata0000024F3387FA28) from UDP 192.168.100.22:5060:
SIP/2.0 200 OK
To: sip:123456@192.168.100.22;tag=1745698426
From: <sip:192.168.100.142>;tag=4d6a45de81e14ad1b00697a8e91adca5
Via: SIP/2.0/UDP 192.168.100.142:5060;rport;branch=z9hG4bKPj3641ddaaca41459d8163bd37bbcfc687
CSeq: 30252 INVITE
Call-ID: c4e8bbbeb83745d0a8cc4bf399bd3a06
Max-Forwards: 70
Contact: <sip:123456@192.168.100.22>
Allow: INVITE, ACK, CANCEL, BYE, INFO, REGISTER, MESSAGE, OPTIONS
Supported: replaces, from-change, 100rel, norefersub
Content-Type: application/sdp
Content-Length: 234

v=0
o=123456 3994237415 3994237415 IN IP4 192.168.100.22
s=pjmedia
a=rtpmap:8 PCMA/8000
c=IN IP4 192.168.100.22
m=audio 5070 RTP/AVP 8 101
a=sendrecv
a=ssrc:900323067
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
t=0 0

--end msg--
14:23:37.058            pjsua_app.c  .....Call 0 state changed to CONNECTING
14:23:37.061    inv0000024F33888670  ....SDP negotiation done: Success
14:23:37.063          pjsua_media.c  .....Call 0: updating media..
14:23:37.068          pjsua_media.c  ......pjmedia_stream_info_from_sdp() failed for call_id 0 media 0: Invalid SDP ssrc attribute (PJMEDIA_SDP_EINSSRC)
14:23:37.071          pjsua_media.c  .......Media stream call00:0 is destroyed
14:23:37.073    udp0000024F33885800  ......UDP media transport destroying
14:23:37.075    udp0000024F33885800  ......UDP media transport destroyed
14:23:37.081          pjsua_media.c  ......Error updating media call00:0: Invalid SDP ssrc attribute (PJMEDIA_SDP_EINSSRC)
14:23:37.084           pjsua_call.c  .....Unable to create media session: No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA) [status=220048]
14:23:37.088           pjsua_core.c  ........TX 408 bytes Request msg BYE/cseq=30253 (tdta0000024F338896B0) to UDP 192.168.100.22:5060:
BYE sip:123456@192.168.100.22 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.142:5060;rport;branch=z9hG4bKPj2449503663b448a1a7ae214a64e90123
Max-Forwards: 70
From: <sip:192.168.100.142>;tag=4d6a45de81e14ad1b00697a8e91adca5
To: sip:123456@192.168.100.22;tag=1745698426
Call-ID: c4e8bbbeb83745d0a8cc4bf399bd3a06
CSeq: 30253 BYE
Reason: SIP ;cause=488 ;text="Unable to create media session"
Content-Length:  0


--end msg--
14:23:37.095           pjsua_core.c  .....TX 345 bytes Request msg ACK/cseq=30252 (tdta0000024F338B2760) to UDP 192.168.100.22:5060:
ACK sip:123456@192.168.100.22 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.142:5060;rport;branch=z9hG4bKPjb2f3230bd3974571aa4c934f3c911cfd
Max-Forwards: 70
From: <sip:192.168.100.142>;tag=4d6a45de81e14ad1b00697a8e91adca5
To: sip:123456@192.168.100.22;tag=1745698426
Call-ID: c4e8bbbeb83745d0a8cc4bf399bd3a06
CSeq: 30252 ACK
Content-Length:  0

[andreas-wehrmann]

I think PJ is right; reading the spec, at least a cname attribute must be specified.
One could make an argument that PJ could be lenient but in this case it would mean to simply ignore the line.
The SDP seems to be "handcrafted" if I may say so.
The line a=rtpmap:8 PCMA/8000 is at the session level and not the media level where it belongs.

Also in the trace you've provided t=0 0 is in the wrong section, this should actually be on the session level.
I don't see a problem in PJ here.

[MGorshkova]

Thanks for the response.
I was a little confused that this wasn't the error in the previous version 2.16.