Inactive video stream: can't find media IP in the message

[schoberw]

Description

In some situations the other side UA must reply with an inactive media stream. E.g. if video was added but not supported by the other side. The UAS then must answer with an m=video 0 RTP/.. line.

It seams that the video section must contain a c= line with an IP address for rtpengine to function. If there is no c line (no IP address) the SDP body cannot be parsed and thus no RTP proxy is invoked.

Troubleshooting

Not easy to reproduce since the answer must bei "wrong". Is it correct to reply an SDP body (media = video) like this?

m=video 0 RTP/AVPF 96
a=label:1
a=inactive
a=mid:1 

Maybe not (but Audiocodes SBC lates LTS version does it) - so we are dependent on other side now that this service works.

Reproduction

reInvite with Video to a UA that has no video Support (e.g. Bria -> Snom). Drop the c line in the video part with some textops in 200 OK (just to reproduce of course).
A -> B, connect the call
A -> + video, B has no video support
A presses hold

Log Messages

Incoming 200 OK after doing hold with an inactive video:

v=0
o=root 436040161 309284577 IN IP4 1.2.3.5
s=call
t=0 0
m=audio 14200 RTP/AVPF 9 8 126
c=IN IP4 1.2.3.5
a=ptime:20
a=recvonly
a=mid:0
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-15
m=video 0 RTP/AVPF 96
a=label:1
a=inactive
a=mid:1
Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: ERROR: <core> [core/parser/sdp/sdp.c:490]: parse_sdp_session(): can't find media IP in the message
Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: INFO: <script>: >>> Sending Reply: 200 OK (1.2.3.4:443 -> 100.108.48.38:65251)

Compare to working SDP parsing:

a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-15
m=video 0 RTP/AVP 96
c=IN IP4 1.2.3.5
a=inactive
a=mid:1
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ONREPLY_ROUTE[FORWARD]
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ROUTE[RTPP_REPLY]
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with video
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with inactive video
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Remove inactive video
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Answer to WebRTC client: 200 - qijpuibkv6ufhnd282ks
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: >>> Sending Reply: 200 OK (1.2.3.4:443 -> 100.108.48.38:65388)

Possible Solutions

Tried to fix in script:

        if(sdp_with_media("video")) xlog("L_INFO", "> $rs with video");
        if(sdp_with_active_media("video")) xlog("L_INFO", "> $rs with active video");
        if(!sdp_with_active_media("video")) xlog("L_INFO", "> $rs with inactive video");

        if(sdp_with_media("video") && !sdp_with_active_media("video")) {
                # try fix for RMT#60189
                xlog("L_INFO", "> Remove inactive video");
                sdp_remove_media("video");
                msg_apply_changes(); # needed?
        }

But since sdpops cannot parse it cannot remove the buggy media, too. See the log: non of the xlog is logging.

If there is inactive media the c line is not mandatory. The parser should accept this by adding a default IP of 0.0.0.0, if needed
Doing tricks with textops is not a easy nor performant solution to accept this wrong SDP from other parties.

Additional Information

version: kamailio 5.6.4 (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, 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_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 10.2.1

• Operating System:

Debian Bullseye

[rfuchs]

This should be addressed in rtpengine, BUT

https://datatracker.ietf.org/doc/html/rfc8866#name-connection-information-c

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.

[schoberw]

Thanks for point to the RFC, that's great for my ticket to Audiocodes :-) Still we do not have any possibilities on our side.
Audiocodes e.g. has some options to fix broken things and move on.

Am I right that the only possibility Kamailio offers is to do it with textops? Still very difficult to check with regex:

• is there a c line above first m line?
• if no, is the a c line after each m line?
• no, not after the 2nd one
• remove 2nd media, but take care on first media, is there a 3rd media?
• was is part of a bundle? Yes: remove the mid from the bundle, too.

This is bad.

But I see the point: yes! It is the others fault.

[miconda]

@schoberw: maybe you can sort it out with the body line cursors:

• https://www.kamailio.org/docs/modules/stable/modules/textopsx.html#textopsx.f.bl_iterator_start

You can also take in consideration to process the body in Lua, JS or Python, via Kemi exports (you can do inline execution of a script, not full replacement of routing blocks with kemi).

I am going to close this one, based on the links to rfc. Further discussions can be done on sr-users mailing list.