Delay in displaying the place holder video

I am using a place holder video instead of camera. It takes exacty 100 secs for the place holder video to appear in the remote side. What could be the reason for this?

On Thursday 12 June 2025 at 14:03:10, prathibhab via Asterisk Community wrote:

I am using a place holder video instead of camera. It takes exacty 100 secs
for the place holder video to appear in the remote side. What could be the
reason for this?

We have no idea until you tell us more about how you have done this and how
you are testing it.

Give us enough informaton to be able to reproduce your setup and we might know
enough to suggest what the problem is.

Antony.


Heisenberg, Gödel, and Chomsky walk in to a bar.
Heisenberg says, “Clearly this is a joke, but how can we work out if it’s
funny or not?”
Gödel replies, “We can’t know that because we’re inside the joke.”
Chomsky says, “Of course it’s funny. You’re just saying it wrong.”

I am using webrtc for making browser based video call. Asterisk is used as the signalling server. For user1 there is no camera. So I am using a place holder video. For user2 there is camera. when user2 makes a video call to user 1, the place holder video of user 1 doesn’t appear in the screen of user 2 initially but appears exactly after 1min 40 secs. This is my issue. This issue is not consistent.

On Thursday 12 June 2025 at 14:22:44, prathibhab via Asterisk Community wrote:

I am using webrtc for making browser based video call. Asterisk is used as
the signalling server.

Give us enough informaton to be able to reproduce your setup and we might
know enough to suggest what the problem is.

Which version of Asterisk is this?
What does the relevant section of your dialplan look like?
What, if anything, appears in log files (a) when the call is placed, and (b)
when the video finally appears?
How are you substituting a placeholder video for a camera? Is this done on
the Asterisk server or on the client without a camera?

We have no idea about any of this detail until you tell us.

At present you’re saying “I have a problem, what could be the cause?” and we
can only say “there must be something wrong with the way you’re doing it”, but
until we know how you are doing it, we cannot suggest any details.

Antony.


I thought I had type A blood, but it turned out to be a typo.

I set up Asterisk for use with WebRTC sip.js clients. I noticed, that the calling party receives no video
till 100s have passed. However the callee receives the remote video immediately. After 100s both parties receive video perfectly. What could be the issue?

I am using asterisk-18 and sip.js-0.20.0

Could this be due to missed frames ?

DTLS packet from x.x.x.x:10263 dropped. ICE not completed yet.
Seeing this warning in asterisk.

Is it an issue with asterisk ? I checked with another turn server, the same issue occurs. ie. the delayed display of video in the caller. I am using directmedia=yes in asterisk sip.conf.

Placeholder video is for the clients without camera. Even with camera on both sides I face this issue. Audio works immediately.

Asterisk log:
Executing [211003@Matrix:1] NoOp(“SIP/8714691684-000000be”, “New Incoming call from number2 8714691684”) in new stack
– Executing [211003@Matrix:2] GotoIf(“SIP/8714691684-000000be”, “0?Kill,selfdial,1”) in new stack
– Executing [211003@Matrix:3] GotoIf(“SIP/8714691684-000000be”, “0?Kill,extnbusy,1”) in new stack
[Jul 4 13:29:17] WARNING[98277][C-00000066]: ast_expr2.fl:468 ast_yyerror: ast_yyerror(): syntax error: syntax error, unexpected ‘!=’, expecting $end; Input:
!=NOT_INUSE
^
[Jul 4 13:29:17] WARNING[98277][C-00000066]: ast_expr2.fl:472 ast_yyerror: If you have questions, please refer to https://wiki.asterisk.org/wiki/display/AST/Channel+Variables
– Executing [211003@Matrix:4] GotoIf(“SIP/8714691684-000000be”, “?Kill,crmoffline,1”) in new stack
– Executing [211003@Matrix:5] Set(“SIP/8714691684-000000be”, “CRMSTATE=NOT_INUSE”) in new stack
– Executing [211003@Matrix:6] Dial(“SIP/8714691684-000000be”, “SIP/211003,20,tT”) in new stack
== Using SIP VIDEO CoS mark 6
== Using SIP RTP CoS mark 5
– Called SIP/211003
– SIP/211003-000000bf is ringing
> 0x7fbd540eede0 – Strict RTP learning after remote address set to: 10.176.16.131:60968
> 0x7fbd541a91d0 – Strict RTP learning after remote address set to: 10.176.16.131:60970
– SIP/211003-000000bf requested media update control 26, passing it to SIP/8714691684-000000be
– SIP/211003-000000bf answered SIP/8714691684-000000be
– Channel SIP/211003-000000bf joined ‘simple_bridge’ basic-bridge <212fa792-aaff-4024-938f-c7b2d35eed07>
– Channel SIP/8714691684-000000be joined ‘simple_bridge’ basic-bridge <212fa792-aaff-4024-938f-c7b2d35eed07>
> 0x7fbd541a91d0 – Strict RTP learning after ICE completion
> 0x7fbd540eede0 – Strict RTP learning after ICE completion
> 0x7fbd541a91d0 – Strict RTP learning after remote address set to: 10.176.16.131:60970
> 0x7fbd540eede0 – Strict RTP learning after remote address set to: 10.176.16.131:60968
> 0x7fbd540eede0 – Strict RTP switching to RTP target address 10.176.16.131:60968 as source
> 0x7fbd541a91d0 – Strict RTP switching to RTP target address 10.176.16.131:60970 as source
> 0x7fbdc81d8130 – Strict RTP learning after ICE completion
> 0x7fbdc81d8130 – Strict RTP learning after remote address set to: 10.216.0.18:10230
> 0x7fbdc8017880 – Strict RTP learning after ICE completion
> 0x7fbdc8017880 – Strict RTP learning after remote address set to: 10.216.0.18:10999
> 0x7fbdc81d8130 – Strict RTP switching to RTP target address 10.216.0.18:10230 as source
> 0x7fbdc8017880 – Strict RTP switching to RTP target address 10.216.0.18:10999 as source
== WebSocket connection from ‘10.203.0.6:53058’ closed
== WebSocket connection from ‘10.176.16.131:1725’ closed
> 0x7fbd540eede0 – Strict RTP learning complete - Locking on source address 10.176.16.131:60968
> 0x7fbd541a91d0 – Strict RTP learning complete - Locking on source address 10.176.16.131:60970
> 0x7fbdc8017880 – Strict RTP learning complete - Locking on source address 10.216.0.18:10999
> 0x7fbdc81d8130 – Strict RTP learning complete - Locking on source address 10.216.0.18:10230
== WebSocket connection from ‘10.203.0.6:56844’ closed

You need to use the full log, not a screen scrape, for any issue which relates to timing.

fulllog.txt (112.8 KB)

caller is 8714691684 and callee is 211003

rtplog.txt (342.4 KB)
RTP log before the video appeared in the caller end.
browserconsolelog.txt (70.6 KB)

sip.conf
[general]
rtcachefriends=yes
qualify=yes
accept_outofcall_message=yes
allowexternalheaders=yes
allowheaders=X-sourceType
media_address=x.x.x.x

remaining settings are given in database.

Initially I used coturn as the turn server. Now I changed to pion turn server. Still facing the same issue.

videoObj.onloadedmetadata = function (e) {
videoEl.show();
videoEl.parent().show();
console.log(“Playing Video Stream MID:”, thisRemoteVideoStream.mid);
RedrawStage(lineObj.LineNumber, true);
}

this code in the browser phone application which uses the sip.js library version 0.20.0, onTrackAddedEvent is getting executed after a delay of 100 secs. The videoWidth and videoHeight is initially 0 and after 100 seconds the videoWidth and videoHeight is getting assigned.

Anything else you require to reproduce the problem?

I’ve tried with browser phone and sipml5 clients, the same issue occurs in both apps.

Similar issue posted in [asterisk-users] Delayed start of video with WebRTC - Missed FIR due to DTLS?

The issue is only with video. Audio appears immediately at both sides.