FreeSWITCH is a crucial component of OnSIP's core architecture. Whether it's our core platform or our latest WebRTC project, OnSIP has always leveraged FreeSWITCH in a fashion that separates us from other service providers.
"Our signaling, user location, and routing all happen on our distributed SIP proxies," says Principal Engineer Eric Tamme. "We use FreeSWITCH as dedicated application servers. This allows us to distribute applications such as conferencing and call parking across many FreeSWITCH instances for scaling and redundancy purposes."
Our latest collaboration with FreeSWITCH aims to solve delay issues that a WebRTC user agent may experience while calling a non-WebRTC user agent. Our engineers have remedied the phenomenon, experienced in FreeSWITCH-based applications, of picking up a call and hearing nothing for the first few seconds. This was accomplished through an innovative reconfiguration of the offer/answer portion of the call. Here are some details:
In a traditional call, a phone sends an INVITE to a device with its offer for media and encryption parameters. When the call is answered, the far end device responds with a 200 OK message with an answer containing its media and encryption options back to the caller. This exchange is the traditional Offer/Answer model. Under this model, there is no way to set up encryption before the call begins, and so users would sometimes be treated to an awkward moment of silence after they have answered the call (while the encryption is being set up).
OnSIP Engineers remedied this situation by changing where the offer/answer negotiation happens. By utilizing a reliable transmission of provisional responses (RFC3262), the media and encryption are actually negotiated before a call is even answered. In this case, the phone initially sends the receiving device an invite with no offer, and the device sends back a 183 early media response with an offer containing media and encryption parameters.
The callee is now the offerer of media, thus inverting the standard offer/answer model. The caller acknowledges the request by sending a PRACK with an answer containing the media and encryption parameters. The callee then sends a 200 OK to the caller, thus completing the exchange, allowing encryption to be set up before a call is even answered. FreeSWITCH previously did not support an answer/offer model within reliable transmission of a provisional response.
OnSIP's development team has created patches to address these issues, and the FreeSWITCH project has accepted them. These new patches have the potential to affect a broad spectrum of offer/answer interactions, and we are excited to utilize them in our own platform to solve delay issues that a WebRTC user agent may experience while calling a non-WebRTC user agent. We look forward to our continued relationship with the FreeSWITCH community and further WebRTC development.