25 Sep
2024
25 Sep
'24
10:29 a.m.
### 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/3982(a)github.com>