No remote video when calling from Android

Asterisk Asterisk SIP
1

Hello everyone,

I have a working implementation of an Asterisk-based videoconferencing platform in React (web). Now I’ve been developing the Android equivalent for a while (using React Native. I can make the call from the phone, answer from the browser on my PC and hear audio on both ends. I can see the local video on both ends. However, I can’t see the remote video on both. Looking at the logs shows that video media is being initialized bundled with audio (same port, as I wanted it to) and that there’s always an incoming video stream. The incoming video stream, however, remains stuck “loading” the video in the video tag (Chrome).

Any idea what could it be? Maybe a codec issue between Chrome and Android?

I’m using JsSIP latest version.

Thank you for your time!

2

I would suggest looking at the negotiated codecs, looking at a packet trace to see the media flowing, as well as looking at webrtc-internals in Chrome to see if anything sticks out on the stream itself.

1 Like
3

Hello jcolp,
thanks for the reply.
I’ve doublechecked every items you suggested and I can’t see any difference
compared to a desktop to desktop kind of videocall except for the fact that asterisk seems
not locking on source for the video on the android IP address:port.
The negotiated codecs are limited to only VP8 for video and in the 200 OK response from
asterisk to android I see that:

<--- Transmitting SIP response (2004 bytes) to WSS:192.168.5.110:55651 --->
SIP/2.0 200 OK
Via: SIP/2.0/WSS videoconf.i-tel.it;rport=55651;received=192.168.5.110;branch=z9hG4bK5143865
Call-ID: vp3ci9j58iovp8fh0m7a
From: <sip:648@videoconf.i-tel.it>;tag=f8q4v47ki0
To: <sip:624@videoconf.i-tel.it>;tag=08dd1dd7-808b-4977-8bf2-598c53612bd3
CSeq: 1575 INVITE
Server: Asterisk PBX 15.3.0
Contact: <sip:192.168.5.220:8443;transport=ws>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 90;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:  1375

v=0
o=- 2374423260 6 IN IP4 192.168.5.220
s=Asterisk
c=IN IP4 192.168.5.220
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE audio video
m=audio 56416 UDP/TLS/RTP/SAVPF 0 126
a=connection:new
a=setup:active
a=fingerprint:SHA-256 D2:DE:DC:2B:8E:1E:85:C9:89:DB:1C:2D:7D:8F:C0:72:A6:C1:33:75:01:E1:0C:5F:90:05:37:7E:AE:2C:21:4C
a=ice-ufrag:054b21bb270e82972afbaada46445061
a=ice-pwd:4d779e9d386f3ddd19fb2bcc77500c4f
a=candidate:Hc0a805dc 1 UDP 2130706431 192.168.5.220 56416 typ host
a=candidate:R259fb8aa 1 UDP 16777215 37.159.184.170 63854 typ relay raddr 192.168.5.220 rport 50338
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:60
a=sendrecv
a=rtcp-mux
a=ssrc:825742657 cname:b84e5b10-c99e-4481-b119-7e1c1dc75a1a
a=msid:95ea97b1-53f0-4a48-b23f-7ef6bca8d72d 4853acce-1257-40cd-a558-d93ffc3cb0cd
a=mid:audio
m=video 56416 UDP/TLS/RTP/SAVPF 96
a=connection:new
a=setup:active
a=fingerprint:SHA-256 D2:DE:DC:2B:8E:1E:85:C9:89:DB:1C:2D:7D:8F:C0:72:A6:C1:33:75:01:E1:0C:5F:90:05:37:7E:AE:2C:21:4C
a=ice-ufrag:054b21bb270e82972afbaada46445061
a=ice-pwd:4d779e9d386f3ddd19fb2bcc77500c4f
a=rtpmap:96 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:2127626911 cname:18464541-fffd-443f-a63e-952f210508dd
a=msid:95ea97b1-53f0-4a48-b23f-7ef6bca8d72d 070b587a-f690-45fa-82ed-3afc5b8cc646
a=rtcp-fb  ccm fir
a=mid:video

but on the RTP side for asterisk I see:

-- Channel PJSIP/624-0000038c joined 'simple_bridge' basic-bridge <3edcf5e8-af59-45d8-bb42-844a4384ec46>
    -- Channel PJSIP/648-0000038b joined 'simple_bridge' basic-bridge <3edcf5e8-af59-45d8-bb42-844a4384ec46>
       > 0x7f49e806ea10 -- Strict RTP learning after remote address set to: 192.168.5.161:64482
       > 0x7f49e806ea10 -- Strict RTP learning after remote address set to: 192.168.5.161:64482
       > 0x7f49e80490b0 -- Strict RTP learning after ICE completion
       > 0x7f49e80490b0 -- Strict RTP switching to RTP target address 192.168.5.161:64482 as source
       > 0x7f49e80ae7b0 -- Strict RTP learning after remote address set to: 192.168.5.110:46169
       > 0x7f49e80b32d0 -- Strict RTP learning after ICE completion
       > 0x7f49e806ea10 -- Strict RTP switching to RTP target address 192.168.5.161:64482 as source
       > 0x7f49e80b32d0 -- Strict RTP switching to RTP target address 192.168.5.110:46169 as source
      > 0x7f49e80490b0 -- Strict RTP learning complete - Locking on source address 192.168.5.161:64482
       > 0x7f49e806ea10 -- Strict RTP learning complete - Locking on source address 192.168.5.161:64482
       > 0x7f49e80b32d0 -- Strict RTP learning complete - Locking on source address 192.168.5.110:46169

where 192.168.5.161 is the desktop while 192.168.5.110 is the android.
So it seems asterisk is missing to lock on source address 192.168.5.110:46169 for the android video.
In the desktop to desktop videocall I see that asterisk is always locking on two sources on same IP address, one for audio and one for video.
Full logs available on request.

Any idea?

Thanks
Franco

4

Have you looked at an actual packet capture to see the media flow? Have you consulted rtp set debug on to see if the packets are being received at all? Don’t tackle the problem as a whole yet. Break it down and isolate it. Have you used Echo with each side to confirm, independently, that they are working correctly?