Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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.
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.
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
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 (91.237.65.14:443 -> 80.108.48.38:65388)
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.
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
Debian Bullseye
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.