Video call hangs up after 30 seconds

Asterisk Asterisk SIP
1

Asterisk 18.6.0
Ubuntu 20.04

I’m trying to establish video call using two softphones (Linphones).
I can successfully make a call, video and audio are transmitted without problem. But, the call hangs up on its own after 30 seconds.

Could anyone guide me what I should do?

There is a warning shown on asterisk log:

[Oct 23 16:15:54] WARNING[187401][C-000000b5]: channel.c:5692 set_format: Unable to find a codec translation path: (vp8|h264|h265) -> (ulaw)

[Oct 23 16:15:54] WARNING[187401][C-000000b5]: channel.c:5692 set_format: Unable to find a codec translation path: (ulaw) -> (vp8|h264|h265)

Here is my sip.conf:

[general] 
context=public                  ; Default context for incoming calls. Defaults to 'default' 
allowguest=no                  ; Allow or reject guest calls (default is yes) 
allowoverlap=no                 ; Disable overlap dialing support. (Default is yes) 
udpbindaddr=0.0.0.0             ; IP address to bind UDP listen socket to (0.0.0.0 binds to all) 
tcpenable=no                    ; Enable server for incoming TCP connections (default is no) 
tcpbindaddr=0.0.0.0             ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces) 
transport=udp                   ; Set the default transports.  The order determines the primary default transport. 
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls 
defaultexpiry=300              ; Default length of incoming/outgoing registration 
videosupport=yes 

localnet=LOCAL_IP
externaddr= SERVER_IP
nat=force_rport,comedia 
canreinvite=no 
directmedia=no 
media_address=SERVER_IP
 
accept_outofcall_message=yes 
outofcall_message_context=message-plan 
auth_message_requests=no

[EXT_NUM]
type=friend
context=phones
host=dynamic
domain=SERVER_IP
qualify=5000
nat=force_rport,comedia
disallow=all
allow=vp8
allow=slin
allow=h264
allow=ulaw
allow=alaw
2

Should be a net, not a node.

Should be your public address, not the ITSP’s.

These are the same, although canreinvite is deprecated.

As per externaddr.

Why?

I think we need the full “sip set debug on” logs, as I don’t know why it is trying to transcode video to audio. Why are you using a deprecated sip channel driver (I believe it was deprecated in Asterisk 17)?

A bad externaddr could well cause a 30 seconds drop, but not just for video. Using an incomplete localnet specification could cause a 30 second dropout, even for intranet phones. What NAT exists between the phones and Asterisk, and how have you configured the phones for any NAT,

Also note that, in most cases you should use type=peer, although there isn’t enough information to know if an exception applies here.

3

Sorry for ambiguity. I was just replacing my IPs.

localnet=172.31.7.6/20

externaddr, media_address are my asterisk server’s public IP.

I used the answer I found on the internet. Commenting it out results the same.

My softphones are in a local network. I believe there is no NAT. I haven’t configured NAT settings on any of the softphones.

Changing it to type=peer leads to the same result. But, since you mentioned, I’ll keep it type=peer.

Please find the attached full sip debug.
sip-debug-video-call.txt (99.6 KB)

Thank you for your response.

4

Also, I’m trying to make a video conference using the softphones. While the softphones can make 30sec video call, there is no video in the conference, but the audio works fine. Do you think it is related to the current problem? or is it a different one?

5

The call is being dropped because Asterisk’s ACK’s on the B leg are not getting through. My best guess is that the problem lies in the router on the site with the two phones. It is the B leg Linphone that is dropping the call, because of not seeing the ACK.

As well as the ACK being completely dropped, it is possible that the router is mangling call ids, tags, and cseq values, inconsistently, so the returned ACK doesn’t match. It is possible that the router, rather than the Linphones, is trying to compensate for the phone’s being behind NAT for signalling.

Also, the SDP in the phones is broken, and is using the private address for the media, so you do need nat=comedia (or comedia=yes, when using the, supported, chan_pjsip, driver). You don’t seem to need force_rport, as the signalling addresses seem to be valid. The reliance on comedia means that you will not be able to send media until you receive media from the respective phone.

You should consider using a VPN, rather than a double NAT traversal with SIP and a phone that doesn’t seem to be properly NAT aware.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.