Call timing out when far end doesn't support RTCP

[Sebastian Murray-Roberts]

Hi there,

I have a question regarding how rtpengine handles peers that do not seem to support RTCP.

I am running Kamailio 5.5.2 and rtpengine mr9.5.3.2.  When making a call to an external endpoint, I don't receive any a=rtcp lines in the 200 OK from the called party. The call is set up just fine and I have perfect two-way audio until one minute in when rtpengine ends the session.

I have timeout set for 60s in rtpengine.conf however I have received rtp for the entire duration, I just do not receive any RTCP reports from the far end so the call is clearly being timed out because of the lack of RTCP.

Is there a way to configure rtpengine to handle this scenario, or must it always receive RTCP in order to keep the session alive?

[Richard Fuchs]

Media timeout handling is not dependent on RTCP. (And also RTCP is not dependent on the presence of `a=rtcp` in the SDP...)

So if your call is terminated due to media timeout despite media flowing, then something else must be going on. Perhaps media is not actually passing through rtpengine? Or something else is triggering the timeout and terminating the call?

Cheers

[Sebastian Murray-Roberts]

Hi Richard,

Thanks for the reply. 

I'm not sure if there's any documentation around it, but is there any other case that could cause a timeout? 

The media is definitely passing through rtpengine:

My RTP path is as follows:

asterisk <-------------> rtpengine <-------------> SIP carrier

Where the Asterisk server IP is redacted in yellow, the rtpengine in green and the SIP carrier is in  blue.

As you can see, the timeout is exactly 60s after the answer command which is in line with the 60s timeout configured in rtpengine.conf.

It's very strange as we have several thousand minutes per day being carried on this trunk, however this issue seems to occur only when dialling one particular number and the only difference I can see is that there is no RTCP being received from our carrier.

[Richard Fuchs]

That is quite odd is this looks like a straight-forward call scenario. As you're a few versions behind on the last LTS update, I'd suggest to update to the latest LTS version first (9.5.4.2 right now) and see if that makes any difference.

If it doesn't, enable debug logging (either globally in the config, or give the "debug" flag to rtpengine when establishing the call) and post the output. In particular the details of the offer/answer signalling are of interest.

(Timeout should only be triggered if none of the RTP streams show any activity in any direction, so activity on even just one stream should keep timeout from being triggered.)

Cheers

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/56ba8ea8-5a77-4e2b-83a1-8211d28c888an%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastian Murray-Roberts]

Hi Richard,

I upgraded the server to 9.5.4.2 however the issue is still happening. I increased the log level to 7 and made a call. The log trace is attached here. The Call-Id in question is  c8f9530e-571b-4e34-bc17-369eb8c8cb70. Call-Id gVECPKr6aZmndhM8TO0AtzQYKuzdcG3f is the the stream from the caller to rtpengine.

Just by way of some context; below is what the architecture looks like. Callers come in from the public internet and send RTP to the rtpengine public interface. The SIP carrier is on a private link and so the RTP interface is the private one.

CALLER --- KAMAILIO_1 ------- ASTERISK ----- KAMAILIO_2 ------ SIP CARRIER
          \                                                                                                 /

             --------------------------------- RTPENGINE -------------------------------

Any insights would be greatly appreciated.

Thanks!

[Richard Fuchs]

On 29/05/2022 15.08, [EXT] Sebastian Murray-Roberts wrote:

Hi Richard,

I upgraded the server to 9.5.4.2 however the issue is still happening. I increased the log level to 7 and made a call. The log trace is attached here. The Call-Id in question is  c8f9530e-571b-4e34-bc17-369eb8c8cb70. Call-Id gVECPKr6aZmndhM8TO0AtzQYKuzdcG3f is the the stream from the caller to rtpengine.

Just by way of some context; below is what the architecture looks like. Callers come in from the public internet and send RTP to the rtpengine public interface. The SIP carrier is on a private link and so the RTP interface is the private one.

CALLER --- KAMAILIO_1 ------- ASTERISK ----- KAMAILIO_2 ------ SIP CARRIER
          \                                                                                                 /

             --------------------------------- RTPENGINE -------------------------------

Any insights would be greatly appreciated.

I notice that you're offering ICE to your B-party (ICE=force in your offer) which the responds with an SDP that contains ICE attributes (ufrag and pwd) but not a single ICE candidate. So your B-party is accepting the ICE offer but isn't providing any candidates to talk to. (This is valid under trickle ICE, where candidates are provided later, but this case isn't trickle ICE.) And this is why your call times out, because ICE fails due to lack of candidates.

In fact your B-party seems to simply mirror back the provided ICE attributes (their content is the same) without understanding what they mean. (UAs like sems tend to do stupid things like that.)

So either fix your B-party so it doesn't erroneously accept ICE when it doesn't actually speak ICE, or don't offer ICE to that B-party to begin with.

Cheers

[Sebastian Murray-Roberts]

Hi Richard,

Setting ICE=remove on the B party side of the call resolved the issue. Thank you so much for your time and quick responses, really appreciate it.

Cheers,

Sebastian