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

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-24349:
----------------------------------------

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.

> 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
>    Affects Versions: 1.8.30.0
>            Reporter: 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)