Re: [rtcweb] Requiring ICE for RTC calls

[Hadriel Kaplan <[e-mail]>]

On Sep 29, 2011, at 6:25 PM, Matthew Kaufman wrote:

> Ridiculous. We're not talking something like one SHA-1 HMAC per packet received... this is one SHA-1 per connectivity test. That's one or two packets *per call*. No way that increases the cost/complexity of any possible device that might be terminating or transcoding media.

Not as far as I know; the SHA-1 hash is calculated on every single STUN request and response packet, because it covers the STUN header which includes the transaction-id, which is unique per request; and the request has different content than the response.  So per ICE-pair connectivity check, it could be two STUN requests and two responses (for the "normal" mode).  And since I'm assuming v4/v6 dual-stack, that's potentially double that number. 

And yes while 8 SHA-1's per call isn't a lot compared to transcoding or terminating media, I wasn't talking about this being done in the PSTN TDM-facing gateways themselves, but rather in the "media-plane gateway" interworking RTCWeb with the legacy SIP world. (ie, SBCs)  At least I assumed that's what people here meant by "media gateways" - it's not like real PSTN-TDM gateways are eager to do ICE... nor are MTAs, voicemail servers, announcement servers, conference servers, IVRs, etc.

And note that I was responding to the emails which made it sound like "all" the SBC has to do is ICE-Lite, and since it has the word "Lite" in it it must therefor be easy/free.  And my point was it's fewer calories, not zero calories. :)

-hadriel
p.s. I should note the arguments in MMUSIC are about this burden for SBCs and v4/v6 transition - not for plain IPv4 and PSTN gateways... not many people expect real PSTN gateways to be involved with ICE, afaict.