RE: [SAFE] nat-control-stun-usage-04

Hi,

Rémi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] wrote:
>>
>> The changes were mostly organizational and editorial, and included:
>>
>>    o  Clarified that all existing bindings, for that source 
>IP address
>>       and UDP port, are controlled with STUN Control.
>>
>>    o  Introduction now concentrates on the primary purpose of STUN
>>       Control, namely reducing keepalive traffic for SIP-Outbound.
>
>As far as I understand, STUN in general, and STUN in 
>particular, can be used for any UDP-based always-on protocol. 
>ESP-in-UDP, TEREDO, perhaps some long usages of RTP (such as 
>MIDI-over-RTP(?) or RTSP-based streaming), proprietary UDP 
>overlays (not giving any names)...
>
>And then, there is the relation to ICE in finding 
>"intermediary" NAT mappings in nested NATs scenarios.
>
>At the same time, I thought SIP Outbound was going to 
>recommend TCP, so that it could end up being a less likely 
>"customer" of STUN control??
>

I agree with Rémi. For protocols like SIP it would be much better to switch to TCP than to build NAT control solutions for UDP. (For instance XMPP uses only TCP and it is proven to scale well.) But there are protocols like those listed above where UDP probably is the only option, and for them controlling UDP NAT bindings makes sense.

Markus 

_______________________________________________
SAFE mailing list
SAFE@ietf.org
https://www1.ietf.org/mailman/listinfo/safe