Remote party changes requests

During a call lifetime, video negotiation may change. For instance, an audio call may become a bidirectional video call or a one-way video call. Or a bidirectional video call may become audio only.

The general principal that guide TPO behavior is simple, sending video to a remote party is a user decision, TPO cannot supersede to this decision and thus will have a conservative approach of video enabling. TPO does not memorize previous video state so moving a video call to monitor may lead to disable video when the call is bring back on handset, the local trader will have to re enable video manually.

Consequently the following table shows what happen when a remote party (whatever this remote party is a turret or a pbx phone) attempt to renegotiate the call at SIP level.

The table consider:

•Remote party, TPO and turrets have all video capabilities enabled

•There exist a call between remote party and one or several traders

•In grey column headers, green arrow represents  remote party requesting to send its own video while blue arrow represent remote party requesting to receive local traders video.

•In white cells, green arrows represent remote party effectively sending his video while blue arrows represent a trader party effectively sending his video to remote party. Cells content represent the resulting state after the remote party has requested video state changes (column headers) depending on "current call state" represented in row headers

For instance, we may see that if remote party request local traders video while no local traders provide video, then TPO will simply negotiate an audio call. If trader wish to provide his local video to remote party, it will be have to do it manually pressing the video button.