[SR-Users] reinvite with 2 video lines in SDP

Filippo Graziola filippo.graziola at gmail.com
Mon Feb 21 15:55:19 CET 2022


Hi all, I'm facing a strange behaviour from a client (iOS application based
on pjsip library) which is doing as follow when receiving a call (on phone
locked):
- accept the call rejecting video (m=video 0...) in SDP
- reinvite to negotiate again video media

Specifically the reinvite passing through kamailio (+rtpengine) has this
SDP body after rtpengine offer (the client use TLS so I can't see the
original message):

v=0
o=- 3854443139 3854443142 IN IP4 PUBLIC_RTP_ENGINE_IP
s=pjmedia
b=AS:386
t=0 0
a=X-nat:0
m=audio 46734 RTP/AVP 8 101
c=IN IP4 PUBLIC_RTP_ENGINE_IP
b=TIAS:96000
a=ssrc:1456418416 cname:441b90ac6db72f22
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:46735
m=video 0 RTP/AVP 96
c=IN IP4 PUBLIC_RTP_ENGINE_IP
b=TIAS:256000
m=video 46776 RTP/AVP 98
c=IN IP4 PUBLIC_RTP_ENGINE_IP
b=TIAS:256000
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42e01e; packetization-mode=1
a=sendrecv
a=rtcp:46777

from this I can understand that the client is doing something strange,
because there is still the rejection line (I know that this question should
go to the pjsip guys) but I would also like to know if it is possible to
"clean" this sdp by kamailio.
A few clients receiving this sdp are answering with only audio.
Reading the docs, sdpops/textops modules allow modifying lines by prefix or
media, but till now I have no luck to exclude only the line "m=video 0
RTP/AVP 96" and his attributes without touching the correct video request.
Could someone please give me some hints on it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220221/098b6f66/attachment.htm>


More information about the sr-users mailing list