[asterisk-dev] [Code Review] res_stun_monitor module

[Simon Perreault]

> On 2010-08-11 13:40:51, Kevin Fleming wrote:
> > /trunk/res/res_stun_monitor.c, line 77
> > <https://reviewboard.asterisk.org/r/854/diff/2/?file=12184#file12184line77>
> >
> >     Should we be concerned about any packets that may have arrived on the socket while the scheduler was waiting to execute this request? If there are any, when the STUN query is sent out, there will be an (apparent) immediate response, and one of the queued packets will be read. It's possible ast_stun_request() already purges the socket of any queued incoming packets, I haven't looked... but if it doesn't, this is probably worth addressing.
> 
> David Vossel wrote:
>     the STUN API does not do this. I will purge the socket before issuing a new request.

Ah I understand now why you're doing that. But it's still wrong. If a packet arrives after you're done purging and before you issue a request, you're still screwed.

What you need to do is two independent things:

a. Send STUN Binding requests every X seconds.
b. Any time a response arrives on the socket, check for an address/port change, and potentially fire an event.

These two things can be done completely independently. You don't need to wait for a response, and you don't need to associate a response with the request that triggered it.


- Simon


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/854/#review2565
-----------------------------------------------------------


On 2010-08-11 16:09:23, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/854/
> -----------------------------------------------------------
> 
> (Updated 2010-08-11 16:09:23)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The res_stun_monitor module monitors the perceived external ip/port provided by a STUN server and sends out an event when that perceived ip/port changes in any way.  This patch adds chan_sip and chan_iax as listeners to this event.  Both of these channel drivers react to the event by regenerating all outbound registers in order to alert the endpoints being registered with to the new address location.  This feature's primary use case is when Asterisk is behind a NAT in which the external ip address is dynamic or the port mappings of the NAT device are subject to change.
> 
> I will update the CHANGES file before committing this.  That is not included within this review though.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_iax2.c 281761 
>   /trunk/channels/chan_sip.c 281761 
>   /trunk/configs/iax.conf.sample 281761 
>   /trunk/configs/res_stun_monitor.conf.sample PRE-CREATION 
>   /trunk/configs/sip.conf.sample 281761 
>   /trunk/include/asterisk/event_defs.h 281761 
>   /trunk/res/res_stun_monitor.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/854/diff
> 
> 
> Testing
> -------
> 
> I tested all the res_stun_monitor.conf options to verify functionality.
> I tested the channel driver's event listening by triggering an address change and verifying registrations are sent via wireshark.
> 
> 
> Thanks,
> 
> David
> 
>