RTP Issues with ChanSIP

Hey everyone,

I know the correct way of dealing with this issue is to migrate to PJSIP, but at the time of writing this, we cannot fully migrate them just yet. ChanSIP=5060 PJSIP=5062, most phones are already on PJSIP, however, the Trunk is still ChanSIP (provider limitation to 5060 only)

Client has one phone number they started using recently to record certain messages. They are complaining that after being on the phone for a while during recording a message, the call drops.

Looking at the logs, I see that the call got disconnected due to the lack of RTP. So I asked them to reproduce a call so I can watch in sngrep.

As shown in the screenshot, I see that when the far end does not play any greetings or when they are recording a message, we don’t receive RTP.

So, I thought that it is an issue with that particular PBX/Setup, so I tried to reproduce on another PBX with a ChanSIP Trunk, same issue. Then is when I tried on another PBX with a PJSIP Trunk and even tho we don’t receive RTP, the PBX does not drop the call!

So my question is: Is there any particular setting that is by default enabled in PJSIP but not in ChanSIP that would allow me to fix this issue in ChanSIP?


Each channel driver have an option for terminating the call if RTP is not received for a period of time. In chan_pjsip it is “rtp_timeout” disabled by default (in Asterisk) and in chan_sip it is “rtptimeout” also disabled by default (in Asterisk).

rtp_timeout is set in Asterisk SIP Settings and afaik, it’s a single field for both drivers.

In /etc/asterisk/asterisk.conf, under [options]

Is this Vitelity? If so, do you have enough clout with them to get them to fix it? They do support arbitrary port numbers if you use registration, and allow you to type in a port number for IP auth, but they then ignore it. This has got to be a trivial fix for them.

Stewart1 is correct, I have a system on Vitelity using registration on an obscure port.

This is to transmit, not to receive. In theory, the far end would need to enable it on their system.

It is not.

Hello @PitzKey,

Try to set RTP keepalive on the sip channels to one second. it sends a CNG (comfort noise generation) frame to keep the session alive especially in NAT environments.

The name of the setting for the chan_sip driver is:

and for chan_pjsip is:

Thank you,

Daniel Friedman
Trixton LTD

For now I simply increased the RTP timeout to 5 minutes which as a workaround is good enough for our client…

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