Re-INVITE Issue With “sendonly” State

Currently WebRTC does not work properly with re-INVITES, re-offers.

For example, if you call to VoIP server and the VoIP server answers with 200 OK with SDP including audio sendonly state(on HOLD).

Chrome browser likes such SDP. However when VoIP server sends re-INVITE with SDP sendrecv, Chrome does not apply the SDP properly and raises internal error.Its known issues related re-INVITE and re-offer, that’s why we should use workaround to avoid such issues. It’s possible to keep WebRTC session in sendrecv state only and perform all HOLD, transfer and other re-invite logic in the server-side proxing session.