There are several considerations that must be made when designing a solution with Audio-Only calls in mind.
Audio Calls can be made from FCSDK by setting the withVideo parameter to false.
call.dial(withAudio, withVideo); |
Caveat: The Live Assist Fusion Client SDK will always initiate an Audio Call with the assumption that video may be added later on in the call. Certain browsers cannot support the addition of video after the initial OFFER/ANSWER request has been made, without establishing a new dialog. The FCSDK will establish a call with active audio and held video. An initial offer will contain a 'recvonly' video attribute; informing the far-side that it will not be receiving any video from the FCSDK.
Below is a diagram of the described negotiation:
Remember, in the scope of FCSDK, placing an audio-only call does not mean the client is not willing to receive Video from the endpoint. This call flow can be used to establish a 1-way video session into a contact-centre; for example, the customer's video is not presented to a contact-centre agent who will be displaying video. In this case the SIP Endpoint ANSWERs the initial OFFER of recvonly with the corresponding hold attribute: sendonly. In this situation, the FCSDK's Media Broker will be expecting to receive video from the Endpoint. Warning: If the endpoint is not capable of sending video having completed this particular call flow, it is extremely likely Chrome will receive audio, but not render the audio output. Chrome always attempts to keep audio and video cues in sync. If there is no video, Chrome will fail to output any audio. This can be verified by observing the inbound audio under the about://webrtc-internals tab. |
Some SIP Endpoints will not support video, however it is important that the FCSDK receives the correct signalling to disable audio to avoid the Warning mentioned above.
As described previously, if Chrome expects to receive Video & Audio, but receives no Video it is likely the audio will not be rendered. This can result in a one-way-media call. The SIP endpoint must send the 'inactive' video attribute in an answer to correctly disable Video. Chrome will correctly render the audio for this call flow. |
Some SIP endpoints will not mark video SDP as inactive, which can once again result in no-media rendering at the FCSDK endpoint.
In this diagram, the SIP Endpoint has sent an ANSWER to the initial OFFER with a black-hole (zeroed) video line. If no changes are made to FCSDK Media Broker, it will insert a sendonly attribute in the ANSWER which will be sent to Chrome. As of FCSDK 3.0.5 - Media Broker will not send any HOLD video to the FCSDK client in Chrome. As a result, once again, the audio will not be rendered. This issue can be resolved by modifying a Media Broker property. It should be made clear this attribute will affect Media Broker's fundamental behaviour and affect all calls. It should not be changed for any other scenario without validating the effects fully. The following attribute must be changed within the Media Broker's installation folder is a file named: proxy.properties: video.hold.on=false Once Media Broker is restarted, on receipt of black-hole SDP, Media Broker will generate an answer with an inactive attribute |
Comments
0 comments
Article is closed for comments.