| 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:49 | Date Closed: | 2018-07-19 03:10:24 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General Resources/res_rtp_asterisk | ||
| Versions: | 1.8.30.0 11.25.3 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| 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: {noformat} > INVITE < 100 < 183, rtp starts < 180, rtp stops < 200, rtp starts {noformat} 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. Thoughts? | ||||
| 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: {code} struct ast_sockaddr addr = { {0,} }; ... ast_rtp_instance_set_remote_address(instance, &addr); {code} 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. | ||||