Subject: Re: [MMUSIC] Re: Use of STUN for RTP keepalives

From: Colin Perkins <[email-masked]>
Date: Sun, 4 Sep 2005 11:53:08 +0100

On 18 Aug 2005, at 03:05, Jonathan Rosenberg wrote:
> Lets look at media and signalling separately.
>
> For media, the benefits of STUN are:
>
> * already in use for the connectivity checks within ICE, making it  
> natural to continue this
> * doesnt interfere with RTCP statistics since its not RTCP
> * generates a response, thus providing a true liveness check as  
> opposed to just keeping nat binding alive
> * works not just for RTP, but any media transport
> * works for any media type or codec (although RTP no-op has the  
> same benefit)
> * allows for detection of network nat failures and reboots that  
> might impact session liveness

There is also the multiplexing issue, which is reintroduced by  
bringing in STUN as a mid-call liveness detector, rather than using  
RTP mechanisms.

> For signaling, it makes sense to use RTP no-op, since there is no  
> benefit to RTP over STUN, both are different than SIP. For  
> signaling, the benefits are:
>
> * generates a resposne thus allows for liveness check of the proxy  
> with very low overhead, allowing it to be sent frequently,  
> improving responsiveness
> * allows for detection of rebooted nats between client and proxy,  
> which would result in an undetectable service outage otherwise

Did you mean to say it makes sense to use STUN? I don't understand  
why you'd use RTP no-op for signalling.

Colin

> -Jonathan R.
>
> Michael Slavitch wrote:
>> Hello,
>> Can I ask what the need is for using STUN rather than simple noop for
>> RTP keepalives?  Doesn't this create additional complexity that  
>> really
>> is not needed?  Likewise for SIP shouldn't a no-op be used for a
>> keepalive to keep the binding alive with a fallback to STUN if the
>> keepalive has failed?
>> Regards,
>> Michael

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic