Re: [rtcweb] Requiring ICE for RTC calls

[Hadriel Kaplan <[e-mail]>]

On Sep 29, 2011, at 10:37 PM, Eric Rescorla wrote:

> Absent some measurements, I tend to agree with Matthew here. 
> My Macbook Air can do roughly 3x10^3 SHA-1 operations per
> second on a single core. In order for this to be 10% of your load,
> you would need to be processing on the order of 
> 75K STUN requests/sec/core. How many total calls/second
> can you do/core w/o STUN?

That's not the problem - the problem is "media" isn't handled in CPUs on many SBCs to begin with.  There're basically two types of SBC architectures in common use: software-based and hardware-based.  The software-based ones don't scale well in terms of concurrent call media capacity (for obvious reasons), so aren't usually used by service providers.  The hardware-based ones do media processing in dedicated hardware (ASICs, NPs, whatever).  To date, most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for STUN messages in their base hardware without either additional hardware components (which costs more money), or they have to send the STUN messages back/forth to their signaling processors on an exception path, which means the overhead isn't just the SHA-1 alone.  So to be fair I shouldn't call it so much the overhead of SHA-1, as the overhead inflicted by going beyond what things like NPs can easily do by themselves (which is the SHA-1 piece).

And this is in the context of the IPv4/v6 debate in MMUSIC, where any additional cost burden for service providers to bear to deploy IPv6 is a sunk cost with no additional revenue and thus very hard to support.  The RTCWeb model is a new "service" in some ways, so the market may bear a different cost burden for it.  

And I haven't been arguing against ICE for RTCWeb - I was a few weeks ago when I was hoping we could get away without it, but I don't see a safe way without it - I was only arguing in this thread against the notion of ICE-Lite being easy/free.

The bigger problem is RTCP for G.711: since many SIP devices don't do RTCP, and there's no way to know if they do/don't from SIP signaling, having to have the SBC's create "fake" RTCP every 5 seconds for every call is a real ball-buster.

-hadriel
p.s. note, the above is based on what I know of 5 different SBC vendors' equipment - there are plenty more than that many SBC vendors in the World, but my assumption is they're not too dissimilar.
p.p.s. some SBCs are "decomposed", meaning separate physical systems doing SIP signaling vs. media processing, and they're usually called things like "BGF" or "AGW" or whatever, but it's logically the same concepts.