[asterisk-bugs] [JIRA] (ASTERISK-29276) stun: Implementation causes delay and doed not work in all network topologies.

[Joshua C. Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp updated ASTERISK-29276:
--------------------------------------

    Summary: stun: Implementation causes delay and doed not work in all network topologies.  (was: Asterisk STUN implementation causes delay and doed not work in all network topologies.)

> stun: Implementation causes delay and doed not work in all network topologies.
> ------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29276
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29276
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 16.16.0
>            Reporter: Chris
>            Severity: Major
>
> Despite of the documentation here https://wiki.asterisk.org/wiki/display/~jcolp/ICE,+STUN,+and+TURN+Support Asterisk does *not* implement this RFC rfc5389. Id rather implements RFC https://tools.ietf.org/html/rfc3489 which is known for it's design flaws.
> {quote}
> However, experience since the publication
>    of RFC 3489 has found that classic STUN simply does not work
>    sufficiently well to be a deployable solution.  The address and port
>    learned through classic STUN are sometimes usable for communications
>    with a peer, and sometimes not.  Classic STUN provided no way to
>    discover whether it would, in fact, work or not, and it provided no
>    remedy in cases where it did not.  Furthermore, classic STUN's
>    algorithm for classification of NAT types was found to be faulty, as
>    many NATs did not fit cleanly into the types defined there.
> {quote}
> The current rfc3489 implementation in stun.c also has serious flaws. E.g. it always waits for 3 seconds before doing a retry. 
> This means, if the UDP packet is dropped, you immediately have a delay of 3 seconds before the call starts.
> {quote}
> 	/* Wait for response. */
> 		{
> 			struct pollfd pfds = { .fd = s, .events = POLLIN };
> 			int ms;
> 			//** Reduce to < 200MS
> 			ms = ast_remaining_ms(start, 3000);
> 			if (ms <= 0) {
> 				/* No response, timeout */
> 				res = 1;
> 				continue;
> 			}
> 			res = ast_poll(&pfds, 1, ms);
> 			if (res < 0) {
> 				/* Error */
> 				continue;
> 			}
> 			if (!res) {
> 				/* No response, timeout */
> 				res = 1;
> 				continue;
> 			}
> 		}
> {quote}
> What should be improved :
> - Implement RFC rfc5389 or use 3rd party STUN library (pjsip ?)
> - Improve wait-loop in stun.c 
> - Update the docs reflecting correct RFC



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