Janus Sip plugin RTP/AVPF problem

General
1

I am making a video call from a sip client (sip phone in this case) to the webrtc client using the Janus sip plugin. There is no problem with audio, but the video does not appear on both sides. When I trace it with Wireshark, I see that there is RTP/AVPF in the invite sent by the sip client, but it is not in the audio line, instead it is RTP/AVP. In the response it returns to the sip client, Janus closes the port for video on the video line.

When I call the SIP client from Webrtc, this problem does not exist. RTP/AVPF is not used at all for incoming and outgoing messages. So I think the problem is caused by RTP/AVPF.

When I looked at the Janus logs, I did not find any logs related to this problem. There is no log regarding RTP/AVPF or setting the video port to 0. Janus’s log level is at the last level, which is 7.

Below I am sharing the SDPs in the invite and 200 ok messages sent by the SIP client and Janus.

Sip client invite:

Explain

v=0
o=LucentPCSF ...
s=-
b=AS:443
b=RS:1200
b=RR:4000
t=0 0
m=audio 40736 RTP/AVP 106 104 110 102 108 0 8 96 97
b=AS:80
b=RS:600
b=RR:2000
a=rtpmap:106 EVS/16000/1
a=fmtp:106 br=5.9-24.4;bw=nb-wb;evs-mode-switch=0;cmr=-1;max-red=0;ch-aw-recv=0
a=rtpmap:104 AMR-WB/16000/1
a=fmtp:104 mode-change-capability=2; max-red=0
a=rtpmap:110 AMR-WB/16000/1
a=fmtp:110 octet-align=1; mode-change-capability=2; max-red=0
a=rtpmap:102 AMR/8000/1
a=fmtp:102 mode-change-capability=2; max-red=0
a=rtpmap:108 AMR/8000/1
a=fmtp:108 octet-align=1; mode-change-capability=2; max-red=0
a=rtpmap:96 telephone-event/16000
a=rtpmap:97 telephone-event/8000
a=sendrecv
a=ptime:20
a=maxptime:60
m=video 29310 RTP/AVPF 114
b=AS:256
b=RS:600
b=RR:2000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=rtpmap:114 H264/90000
a=fmtp:114 profile-level-id=42C00C;packetization-mode=1;sar-understood=16;sar-supported=1;sprop-parameter-sets=Z0LADNoPCmgG0KE1,aM4G4g==
a=sendrecv
a=extmap:2 urn:3gpp:video-orientation

Janus 200 ok answer:

Explain

v=0
o=- 7584780845682629818 2010363203627160449 IN IP4 206.10.88.76
s=-
c=IN IP4 206.10.88.76
t=0 0
m=audio 23992 RTP/AVP 0 8 97
c=IN IP4 206.10.88.76
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=mid:0
a=msid:77fc570e-cb83-499c-abd1-2a1c491fbbac fed5a407-6319-4d5b-a8f9-0ed4bc279ba4
m=video 0 RTP/AVPF 19
2

The SIP plugin only “understands” AVP, and doesn’t keep track of the profile the peer sets. So if you set AVPF in an INVITE, AVP is what you’ll get back. It works fine in the other case because it’s the SIP plugin that offers AVP, and AVP is what is answered by the SIP peer.