### 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: &lt;kamailio/kamailio/issues/3982(a)github.com&gt;