How to resolve the issue?
There is 1 minute difference between the server and client clock. That may be the issue.
There are no time stamps, which normally means that this is a screen scrape of the console, not the full log, requested, and means I’ve no idea if there is a 100 second gap somewhere in this sequence.
> 0x7fbdbc031b30 -- Strict RTP learning after remote address set to: 10.176.16.131:50579
> 0x7fbdbc02bfe0 -- Strict RTP learning after remote address set to: 10.176.16.131:50577
> 0x7fbdbc02bfe0 -- Strict RTP switching to RTP target address 10.176.16.131:50577 as source
> 0x7fbdbc031b30 -- Strict RTP switching to RTP target address 10.176.16.131:50579 as source
<--- SIP read from WS:10.203.0.6:53908 --->
ACK sip:211003@10.216.0.18:5060;transport=ws SIP/2.0
Via: SIP/2.0/WSS 192.0.2.70;branch=z9hG4bK9852373
To: <sip:211003@bpdev.erss.in>;tag=as011a7efd
From: "TN_CAD_006" <sip:8714691684@bpdev.erss.in>;tag=k88j0ft5jt
CSeq: 2 ACK
Call-ID: 5fmhaqkatlre2orii801
Max-Forwards: 70
Supported: outbound
User-Agent: Browser Phone 0.3.20 (SIPJS - 0.20.0) Mozilla/5.0 (Linux; Android 14; SM-A146B Build/UP1A.231005.007; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/137.0.7151.116 Mobile Safari/537.36
Content-Length: 0
<------------->
--- (10 headers 0 lines) ---
> 0x7fbda803ff90 -- Strict RTP learning after ICE completion
> 0x7fbda804a2e0 -- Strict RTP learning after ICE completion
> 0x7fbda803ff90 -- Strict RTP learning after remote address set to: 10.216.0.18:10480
> 0x7fbda804a2e0 -- Strict RTP learning after remote address set to: 10.216.0.18:10221
> 0x7fbda804a2e0 -- Strict RTP switching to RTP target address 10.216.0.18:10221 as source
> 0x7fbda803ff90 -- Strict RTP switching to RTP target address 10.216.0.18:10480 as source
Really destroying SIP dialog 'gdtvp64830ti454dadlh' Method: REGISTER
Really destroying SIP dialog '4jh56ehrhnqu534lo72l' Method: REGISTER
Really destroying SIP dialog '177dncnmmta0q2r6v88v' Method: REGISTER
> 0x7fbdbc02bfe0 -- Strict RTP learning complete - Locking on source address 10.176.16.131:50577
> 0x7fbdbc031b30 -- Strict RTP learning complete - Locking on source address 10.176.16.131:50579
> 0x7fbda804a2e0 -- Strict RTP learning complete - Locking on source address 10.216.0.18:10221
> 0x7fbda803ff90 -- Strict RTP learning complete - Locking on source address 10.216.0.18:10480
Also, if key frames are 100s apart, I’d suggest that is totally unsuitable for dial up access. It might be OK for continuous surveillance, from a fixed camera.
> [Jul 9 05:43:16] > Saved useragent "Browser Phone 0.3.20 (SIPJS - 0.20.0) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36 Edg/138.0.0.0" for peer 211003
> [Jul 9 05:43:16] NOTICE[299323]: chan_sip.c:25009 handle_response_peerpoke: Peer '211003' is now Reachable. (84ms / 2000ms)
> [Jul 9 05:43:17] NOTICE[299323]: chan_sip.c:28829 handle_request_subscribe: Received SIP subscribe for peer without mailbox: 211003
> [Jul 9 05:43:35] -- Registered SIP '211004' at 10.176.17.15:62012
> [Jul 9 05:43:39] == WebSocket connection from '10.203.0.6:36690' for protocol 'sip' accepted using version '13'
> [Jul 9 05:43:40] -- Registered SIP '9962466480' at 10.203.0.6:36690
> [Jul 9 05:43:40] NOTICE[299417]: chan_sip.c:25009 handle_response_peerpoke: Peer '9962466480' is now Reachable. (80ms / 2000ms)
> [Jul 9 05:43:40] == Manager 'ners' logged on from 127.0.0.1
> [Jul 9 05:43:40] == Manager 'ners' logged off from 127.0.0.1
> [Jul 9 05:43:41] NOTICE[299417]: chan_sip.c:28829 handle_request_subscribe: Received SIP subscribe for peer without mailbox: 9962466480
> [Jul 9 05:43:44] == Using SIP VIDEO CoS mark 6
> [Jul 9 05:43:44] == Using SIP RTP CoS mark 5
> [Jul 9 05:43:44] > 0x7f1128038650 -- Strict RTP learning after remote address set to: 14.139.173.219:10071
> [Jul 9 05:43:44] -- Executing [211003@Matrix:1] NoOp("SIP/9962466480-00000036", "New Incoming call from number2 9962466480") in new stack
> [Jul 9 05:43:44] -- Executing [211003@Matrix:2] GotoIf("SIP/9962466480-00000036", "0?Kill,selfdial,1") in new stack
> [Jul 9 05:43:44] -- Executing [211003@Matrix:3] GotoIf("SIP/9962466480-00000036", "0?Kill,extnbusy,1") in new stack
> [Jul 9 05:43:44] WARNING[299439][C-0000001c]: ast_expr2.fl:468 ast_yyerror: ast_yyerror(): syntax error: syntax error, unexpected '!=', expecting $end; Input:
> !=NOT_INUSE
> ^
> [Jul 9 05:43:44] WARNING[299439][C-0000001c]: ast_expr2.fl:472 ast_yyerror: If you have questions, please refer to https://wiki.asterisk.org/wiki/display/AST/Channel+Variables
> [Jul 9 05:43:44] -- Executing [211003@Matrix:4] GotoIf("SIP/9962466480-00000036", "?Kill,crmoffline,1") in new stack
> [Jul 9 05:43:44] -- Executing [211003@Matrix:5] Set("SIP/9962466480-00000036", "CRMSTATE=UNAVAILABLE") in new stack
> [Jul 9 05:43:44] -- Executing [211003@Matrix:6] Dial("SIP/9962466480-00000036", "SIP/211003,20,tT") in new stack
> [Jul 9 05:43:44] == Using SIP VIDEO CoS mark 6
> [Jul 9 05:43:44] == Using SIP RTP CoS mark 5
> [Jul 9 05:43:44] -- Called SIP/211003
> [Jul 9 05:43:44] -- SIP/211003-00000037 is ringing
> [Jul 9 05:43:52] > 0x7f112803e6b0 -- Strict RTP learning after ICE completion
> [Jul 9 05:43:55] -- SIP/211003-00000037 answered SIP/9962466480-00000036
> [Jul 9 05:43:55] -- Channel SIP/211003-00000037 joined 'simple_bridge' basic-bridge <f46d8759-1de1-4b45-a51b-cb0b709a4769>
> [Jul 9 05:43:55] -- Channel SIP/9962466480-00000036 joined 'simple_bridge' basic-bridge <f46d8759-1de1-4b45-a51b-cb0b709a4769>
> [Jul 9 05:43:55] > 0x7f113002e780 -- Strict RTP learning after ICE completion
> [Jul 9 05:43:55] > 0x7f113002e780 -- Strict RTP learning after remote address set to: 10.216.0.18:10003
> [Jul 9 05:43:55] > 0x7f11301b32b0 -- Strict RTP learning after ICE completion
> [Jul 9 05:43:55] > 0x7f11301b32b0 -- Strict RTP learning after remote address set to: 10.216.0.18:10290
> [Jul 9 05:43:55] > 0x7f1128038650 -- Strict RTP learning after ICE completion
> [Jul 9 05:43:55] > 0x7f11301b32b0 -- Strict RTP switching to RTP target address 10.216.0.18:10290 as source
> [Jul 9 05:43:55] > 0x7f112803e6b0 -- Strict RTP learning after remote address set to: 10.216.0.18:10344
> [Jul 9 05:43:55] > 0x7f1128038650 -- Strict RTP learning after remote address set to: 10.216.0.18:10071
> [Jul 9 05:43:55] > 0x7f113002e780 -- Strict RTP switching to RTP target address 10.216.0.18:10003 as source
> [Jul 9 05:43:55] > 0x7f1128038650 -- Strict RTP switching to RTP target address 10.216.0.18:10071 as source
> [Jul 9 05:43:59] > 0x7f112803e6b0 -- Strict RTP switching to RTP target address 10.216.0.18:10344 as source
> [Jul 9 05:44:00] > 0x7f113002e780 -- Strict RTP learning complete - Locking on source address 10.216.0.18:10003
> [Jul 9 05:44:00] > 0x7f11301b32b0 -- Strict RTP learning complete - Locking on source address 10.216.0.18:10290
> [Jul 9 05:44:00] > 0x7f1128038650 -- Strict RTP learning complete - Locking on source address 10.216.0.18:10071
> [Jul 9 05:44:00] > 0x7f112803e6b0 -- Strict RTP learning complete - Locking on source address 10.216.0.18:10344
full.txt (9.8 MB)
FWIIW, and without even looking at the details, I had a similar problem once where the remote video took almost 2 minutes to show up. I fixed it by setting direct media to yes. Of course I am using pjsip. The SIP.conf channel is deprecated.
I’m also using directmedia=yes.
Your problem description is not consistent. This is what you have said at various times:
It takes exacty 100 secs for the place holder video to appear in the remote side
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.
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
Placeholder video is for the clients without camera
So my question:
If the callee is getting the video immediately, and this setup is for callers that don’t have cameras, what’s the problem?
If the caller isn’t getting video until after 100 seconds and the callee doesn’t have a camera what’s the problem?
Do you see the problem here?
Your clients seem to be very undefined here. One moment they have cameras. One moment they don’t. There does not seem to be rhyme or reason which side - the caller or the callee, user 1 or user 2 - has a camera in any given example.
You also asked if we could reproduce the problem. Nobody is going to try reproducing anything without a complete set of configs. Nobody is also going to try reproducing anything using the chan_sip driver even if you did post a complete set of configs. You would also need to post a complete setup of configs of the web page you have your softphone embedded in. In other words - you would have to lay out the red carpet with a set of instructions on how to duplicate your test bed before anyone is going to even try reproducing it and even then, nobody probably will if they can see an error anywhere in your config.
There really isn’t anything here that anyone can use for troubleshooting because you’re not being forthcoming or open in your description. Most times I have seen problems spin here is because of that - the person with the question thinks that this forum is like tick-tock where you get penalized the longer and more data that’s posted. So they tickle-truth out the details of their problem in dribs and drabs and people answering play that game for a while then get tired of it and the OP is then left frustrated with no answer.
This forum is an old-school troubleshooting forum. You get penalized the shorter the question for help is. It’s not a new-school forum with idiots leading other idiots to do idiot things like eating detergent pods or whatever stupidity people are currently trying to outdo each other with on their phones.