You need to look at the “sip set debug on” logging to see where the SDP is telling the other party to send the RTP (c= line), and to which port (m= line) and confirm that your router is forwarding that port.
However note that chan_sip is scheduled for removal in the 2023 version of Asterisk, and has no active maintainer.
We have a firewall running and it could be blocking, I will have to talk to our networks guy next week, a quick question though, is port 14854 set to be used all the time or is it random? I am asking this because i noticed while setting up soft phones, i thought they would be always be using 5060/5061 but when i do sip show peers i see they are using some random ports, so to solve this if i ask the network admin to allow port 14854 will it be the one used all the time?
@david55 & @comtech So the networks guy allowed the 10-20000 ports range, but still my calls disconnect after 30s with the same “lack of RTP activity in 31 seconds”.
@david55 I get the same even with pjsip extensions as you can see below:
– Called PJSIP/202/sip:[email protected]:57465;transport=TCP;rinstance=1388e0496bc9efcb
== Using SIP RTP Audio TOS bits 184
== Using SIP RTP Audio TOS bits 184 in TCLASS field.
== Using SIP RTP Audio CoS mark 5
– PJSIP/202-00000003 is ringing
> 0x7f416402f010 – Strict RTP learning after remote address set to: 192.168.1.143:8000
– PJSIP/202-00000003 answered PJSIP/201-00000002
> 0x7f4164040d00 – Strict RTP learning after remote address set to: 192.168.1.149:8000
– Channel PJSIP/202-00000003 joined ‘simple_bridge’ basic-bridge
– Channel PJSIP/201-00000002 joined ‘simple_bridge’ basic-bridge
[2022-01-24 18:04:39] WARNING[83699]: res_pjsip_pubsub.c:3353 pubsub_on_rx_publish_request: No registered publish handler for event presence from 202
[2022-01-24 18:04:39] WARNING[83699]: res_pjsip_pubsub.c:787 subscription_get_handler_from_rdata: No registered subscribe handler for event presence.winfo from 202
[2022-01-24 18:04:39] WARNING[83699]: res_pjsip_pubsub.c:3353 pubsub_on_rx_publish_request: No registered publish handler for event presence from 201
[2022-01-24 18:04:39] WARNING[83699]: res_pjsip_pubsub.c:787 subscription_get_handler_from_rdata: No registered subscribe handler for event presence.winfo from 201
[2022-01-24 18:04:39] WARNING[83699]: res_pjsip_pubsub.c:3353 pubsub_on_rx_publish_request: No registered publish handler for event presence from 202
[2022-01-24 18:04:39] WARNING[83699]: res_pjsip_pubsub.c:787 subscription_get_handler_from_rdata: No registered subscribe handler for event presence.winfo from 202
[2022-01-24 18:05:03] WARNING[83699]: res_pjsip_pubsub.c:3353 pubsub_on_rx_publish_request: No registered publish handler for event presence from 202
[2022-01-24 18:05:03] WARNING[83699]: res_pjsip_pubsub.c:787 subscription_get_handler_from_rdata: No registered subscribe handler for event presence.winfo from 202
[2022-01-24 18:05:09] NOTICE[62031]: res_pjsip_sdp_rtp.c:149 rtp_check_timeout: Disconnecting channel ‘PJSIP/202-00000003’ for lack of audio RTP activity in 39 seco nds
– Channel PJSIP/202-00000003 left ‘simple_bridge’ basic-bridge
– Channel PJSIP/201-00000002 left ‘simple_bridge’ basic-bridge
== Spawn extension (macro-dial-one, s, 56) exited non-zero on ‘PJSIP/201-00000002’ in macro ‘dial-one’
== Spawn extension (macro-exten-vm, s, 30) exited non-zero on ‘PJSIP/201-00000002’ in macro ‘exten-vm’
== Spawn extension (ext-local, 202, 3) exited non-zero on ‘PJSIP/201-00000002’
– Executing [h@ext-local:1] Macro(“PJSIP/201-00000002”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“PJSIP/201-00000002”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“PJSIP/201-00000002”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] NoOp(“PJSIP/201-00000002”, "PJSIP/202-00000003 montior file= ") in new stack
[2022-01-24 18:05:09] NOTICE[62031]: res_pjsip_sdp_rtp.c:149 rtp_check_timeout: Disconnecting channel ‘PJSIP/201-00000002’ for lack of audio RTP activity in 39 seco nds
– Executing [s@macro-hangupcall:5] GotoIf(“PJSIP/201-00000002”, “1?skipagi”) in new stack
– Goto (macro-hangupcall,s,7)
– Executing [s@macro-hangupcall:7] Hangup(“PJSIP/201-00000002”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 7) exited non-zero on ‘PJSIP/201-00000002’ in macro ‘hangupcall’
== Spawn extension (ext-local, h, 1) exited non-zero on ‘PJSIP/201-00000002’
[2022-01-24 18:05:09] WARNING[83699]: res_pjsip_pubsub.c:787 subscription_get_handler_from_rdata: No registered subscribe handler for event presence.winfo from 202
[2022-01-24 18:05:09] WARNING[83699]: res_pjsip_pubsub.c:3353 pubsub_on_rx_publish_request: No registered publish handler for event presence from 202
[2022-01-24 18:05:09] WARNING[83699]: res_pjsip_pubsub.c:3353 pubsub_on_rx_publish_request: No registered publish handler for event presence from 201
[2022-01-24 18:05:09] WARNING[83699]: res_pjsip_pubsub.c:787 subscription_get_handler_from_rdata: No registered subscribe handler for event presence.winfo from 201
I notice that you are using TCP for a transport, not a problem but not the default, but further you have
0x7f4164040d00 – Strict RTP learning after remote address set to: 192.168.1.149:8000
which would seem that somehow you are forcing the media port to 8000 which is not covered by your forwarding rules, perhaps a typo or conflation with your rtp codec mapping somewhere ?
Maybe start with a bog-standard UDP extension . . .
The problem description seems strange. Please confirm that calls lasting less than 30 seconds have normal audio in both directions and there is no apparent trouble. If not, what is the first thing that goes wrong, e.g. “no incoming audio” or “no audio in either direction”.
Also, what is the simplest failing case? Are calls between extensions ok? Calls to *43 (echo test)?
@dicko when i change transport to UDP in my softphone it fails to register at all, so that’s why i am using TCP. @ashcortech I believe the 30s timeout its using is in SIP Settings RTP Timeout. @Stewart1 there is no audio at all.
Happy to report that it worked, @david55 and the rest who suggested blocking of the port by firewall were right, apparently UDP packets were being blocked, now I am able to register my extensions using UDP as transport and my calls are not dropping after 30s. Thanks everyone who help on this.