Re: [rtcweb] STUN for keep-alive - RTCP-less applications

["Olle E. Johansson" <[e-mail]>]

19 sep 2011 kl. 13:19 skrev Hadriel Kaplan:

> 
> I agree for rtcweb <-> rtcweb, but for going to/from non-rtcweb devices this is a problem.  Unfortunately lots of SIP devices don't generate RTCP.  Undoubtedly going to non-rtcweb will often require gateways of some form or other in the media plane, if for nothing else than ICE termination; but making such gateways generate fake RTCP is asking for the price to go up.  :(
> 
That takes us back to the core question: How much should we let the old luggage of SIP affect the architecture of the new shining stuff we're creating here?

I agree that the SIP world has failed in implementing RTCP. Maybe we should discuss why and see what we can come up with. Some of my observations from working with RTCP in SIP:

 - NAT effects on the RTCP stream is mostly not handled
 - RTCP Bye is not really used 
 - Some devices have a policy/setting that says "Send RTCP every Y minute". Calls under Y minutes doesn't get RTCP, not even a BYE with final status
 - A well-known vendor sends RTCP with time stamps from year 2031

I think the coupling between actual codec quality and RTCP is missing with the ALAW/ULAW codecs. With more adaptive codecs and of course video, RTCP is becoming a requirement.  The current PSTN-centric mostly ALAW/ULAW SIP devices only needs RTCP to measure quality after the call is over which means that it's not a selling feature.

So if we rephrase the issue: I think RTCP should be a MUST for rtcweb implementations. However, calls should not fail when communicating with RTP implementations that doesn't send RTCP. 

/O

> -hadriel
> 
> 
> On Sep 19, 2011, at 2:35 AM, Olle E. Johansson wrote:
> 
>> 
>> 18 sep 2011 kl. 23:10 skrev Harald Alvestrand:
>> 
>>> I don't think we want to support RTCP-less applicaitons; if saying "no" to them helps them not occur (it doesn't always help...)
>> 
>> No, we don't want to support applications without RTCP. +1.
>> 
>> /O