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

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

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.


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