Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)

[Saúl Ibarra Corretgé <[e-mail]>]

Hi,

Sorry for coming a bit late...

> 
> You just repeated the same thing that I said, just a bit more clearly. 
> 
> I guess we are making a conscientious not to be able to communicate with any of the existing VoIP infrastructure including IP phones and SIP trunking providers and expect them to implement ICE support. Until this happens RTC end points will have to rely on some sort of media proxy to communicate with existing infrastructure. Is this correct?
> 
> Do we have anybody in this list who has real life experience with deploying large scale ICE based solutions over public internet? I just want to make sure that we are not putting all of our eggs in the basket that no one ever used.

We do deploy ICE-enabled network infrastructure to our customers, the free http://sip2sip.info site is an example of such a platform.

The problem we faced with ICE was the fact that in most cases NAT is fixed by modifying the SDP and changing c/m lines in order to put a media relay in between, but this breaks ICE negotiation because there is no candidate for the new c line. We solved this in two Open Source projects: OpenSIPS and MediaProxy by also adding a new candidate which would appear to be a TURN server, so both ends are fooled to believe there was a candidate. The media relay lets STUN probes pass so that ICE connectivity checks will succeed.

This ensures that if both endpoints do support ICE the negotiation will succeed. Unfortunately, not many endpoints do implement ICE, so those that don't would need to be gateway-ed, but IMHO it's for a greater good.


Regards,

--
Saúl Ibarra Corretgé
AG Projects