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

Walter Doekes (JIRA) noreply at issues.asterisk.org
Fri Sep 26 15:29:29 CDT 2014


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

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

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

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



More information about the asterisk-bugs mailing list