Summary:ASTERISK-24349: strictrtp has trouble in NAT scenario's with 100->183->180->200
Reporter:Walter Doekes (wdoekes)Labels:
Date Opened:2014-09-22 15:41:49Date Closed:2018-07-19 03:10:24
Status:Closed/CompleteComponents:Channels/chan_sip/General Resources/res_rtp_asterisk
Versions: 11.25.3 Frequency of
is related toASTERISK-28686 chan_sip strictrtp=yes fails when media source is changed: no audio
Description:While deploying strictrtp=yes, we ran into the problem that one of our ITSPs has a tendency to send 183 before 180.

This causes a SIP+RTP flow like this:
< 100
< 183, rtp starts
< 180, rtp stops
< 200, rtp starts

During the 183, asterisk has enough time to "learn" the RTP address of remote, and lock it.

But then, at the 180, the client device stops sending RTP.

At the 200, the client device resumes sending RTP, but this is now on a completely different port. (Probably due to NAT, but perhaps by the phones choice, I did not investigate.)

*Result*: strict rtp failure.

*Possible solution*: do an extra call to {{ast_rtp_instance_set_remote_address}} on sending the {{200}} or receiving the {{ACK}}, so that the learning may restart.

Comments:By: Matt Jordan (mjordan) 2014-09-22 15:46:26.239-0500

I think I'd be okay with doing that on the 200 OK, *if* RTP was stopped.

I don't think we'd want to do it unilaterally, as re-starting learning may cause a short audio drop.

By: Walter Doekes (wdoekes) 2014-09-22 15:51:15.604-0500

You wouldn't happen to know how I know whether rtp is stopped?

Because in the failed example, I saw asterisk continuing to send, while only remote stopped sending.

And if there is an easy way to know that it stopped, shouldn't we use that as a trigger to restart learning?

By: Rusty Newton (rnewton) 2014-09-24 17:44:25.337-0500

Since others may not be watching this issue, you guys might bring this up on the dev list to discuss there.

By: Matt Jordan (mjordan) 2014-09-26 15:10:38.257-0500

When the RTP engine is stopped, the remote address will be 0:

struct ast_sockaddr addr = { {0,} };

ast_rtp_instance_set_remote_address(instance, &addr);

You can check to see if the remote address is 0 using {{ast_rtp_instance_get_remote_address}}. If so, then you know that no RTP is flowing.

By: Walter Doekes (wdoekes) 2014-09-26 15:27:49.372-0500

> When the RTP engine is stopped, the remote address will be 0

Correct me if I'm wrong, but if asterisk was still sending RTP, the RTP engine was probably not "stopped".

I would think that the remote_address would still point to the first-learned RTP address, the one we would like to forget.

By: Joshua C. Colp (jcolp) 2017-12-18 09:36:16.197-0600

Hey Walter, I see this has been assigned to you for quite some time. (How time flies). Did anything ever come of this?

By: Walter Doekes (wdoekes) 2017-12-18 10:14:33.044-0600

We did finally switch over to strictrtp=yes (latest security-patched Asterisk 11.x), but I hear some devices (Swyft PBX?) are now forcibly put on a separate Asterisk with strictrtp=no. I haven't been involved in that, but I the problem is probably exactly the same still.

I'll go check and report back.

By: Walter Doekes (wdoekes) 2018-01-16 02:24:36.297-0600

I haven't forgotten about this. Getting the victims to reproduce just takes a bit more effort/bureaucracy.

By: Walter Doekes (wdoekes) 2018-01-16 02:28:12.966-0600

P.S. My perms to move this into Requesting Feedback state are gone. Someone else may move it back.

P.S.2. The last I hear was that the accounts were moved to a strictrtp=no machine because of trouble with call transfers.

By: Walter Doekes (wdoekes) 2018-07-19 03:09:48.357-0500

Cannot find the time to tackle this. I'll reopen when/if I get more info.