[asterisk-bugs] [JIRA] (ASTERISK-24349) strictrtp has trouble in NAT scenario's with 100->183->180->200

[Walter Doekes (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240735#comment-240735 ] 

Walter Doekes commented on ASTERISK-24349:
------------------------------------------

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.

> strictrtp has trouble in NAT scenario's with 100->183->180->200
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-24349
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24349
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Resources/res_rtp_asterisk
>    Affects Versions: 1.8.30.0
>            Reporter: Walter Doekes
>            Assignee: Walter Doekes
>
> 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?



--
This message was sent by Atlassian JIRA
(v6.2#6252)