[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=222737#comment-222737 ] 

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

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?

> 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)