### Description
I encountered an issue with a specific device that is receiving a T.38 fax. The
call gets established towards the device normally with inband media, then the
device requests T.38 media and tries to remove the audio media via sending port
0 in the ReInvite SDP. Also it sends connection-information only on the media
level and there is no "c=" on the session level.
Reading through the related RFCs and the kamailio code and discussing this on
the mailing list, we came to the conclusion that kamailio is doing everything
correct as per RFC. Though we were wondering if it would be possible to adjust
the parser to be not as strict as it is right now, and allow a missing "c="
line on the media-level if the stream is removed/rejected via port 0, since i
see no sense in requiring connection information. Of course we are also in
contact with the vendor to hopefully adjust on their side.
Here are the related RFCs:
1. RFC8866 5.7
`A session description MUST contain either at least one "c=" line in each media
description or a single "c=" line at the session level. It MAY contain a single
session-level "c=" line and additional media-level "c=" line(s)
per-media-description, in which case the media-level values override the
session-level settings for the respective media.`
2. RFC3264 8.2
`Existing media streams are removed by creating a new SDP with the port number
for that stream set to zero. The stream description MAY omit all attributes
present previously, and MAY list just a single media format.`
At first i was especially confused by the RFC3264 8.2 part, since it seemed
correct what the device is sending, but if you read carefully and keep the
wording for SDP in mind only attributes ("a=") MAY be omitted. So a "c=" line
should still be in the SDP for the removed media if it's not included on the
session-level. Or do you see this differently?
### Expected behavior
Kamailio allows and parses the SDP when there is no session-wide "c=", a media
stream is being removed via port zero and there is no "c=" for this media
stream and only the remaining media streams include a "c=" line.
#### Actual observed behavior
Kamailio throws an error when trying to parse the SDP.
#### Log Messages
```
<core> [core/parser/sdp/sdp.c:523]: parse_sdp_session(): can't find media IP in
the message
```
#### SIP Traffic
```
v=0
o=xmserver 1726638425 1726638427 IN IP4 169.254.1.1
s=xmserver
t=0 0
m=audio 0 RTP/AVP 8
m=image 56002 udptl t38
c=IN IP4 169.254.1.1
a=sendrecv
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy
```
### Possible Solutions
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.8.3 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC,
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES,
TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE
262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 12.2.0
```
* **Operating System**:
```
Debian 12
Linux hostname 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1
(2024-04-11) x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3982
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3...@github.com>_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
