[asterisk-dev] [asterisk-commits] file: trunk r369858 - /trunk/main/stun.c

[Kevin P. Fleming]

On 07/10/2012 11:19 AM, Joshua Colp wrote:
> ----- Original Message -----
>> On 07/09/2012 05:38 PM, SVN commits to the Asterisk project wrote:
>>> Author: file
>>> Date: Mon Jul  9 17:38:25 2012
>>> New Revision: 369858
>>>
>>> URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=369858
>>> Log:
>>> When receiving a STUN binding request send one out as the Google
>>> Talk client uses this as a method to determine if the remote party
>>> is still reachable or not.
>>>
>>> Failure to do this results in the Google Talk client ignoring RTP
>>> packets after a specific period of time. This is also done as a
>>> result of receiving a STUN binding request so that the username
>>> information can be used from the inbound request, thus not
>>> requiring it to be stored on a per candidate basis.
>>>
>>> (closes issue ASTERISK-20107)
>>> Reported by: Malcolm Davenport
>>
>> Maybe I'm missing something, but if someone has two Asterisk systems
>> peered, and one sends a STUN binding request to the other, won't this
>> result in an infinite series of binding requests and responses?
>
> The only time the legacy STUN code is used in this fashion is when the Google Jingle or Google Talk protocol is in use. This should only be used when talking to an actual Google Talk client, not when communicating with another Asterisk. For communicating with Asterisk the official Jingle protocol is used which uses the pjnath provided ICE/STUN/TURN support.

OK, so the risk is if any *new* code is introduced which attempts to use 
the legacy STUN code in this way. That should be caught during code 
review, though :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org