Muting/Unmuting a Party in a Conference

Starting with release 8.1.102.02, SIP Server allows any conference party on the call to mute or unmute any internal party in a conference. One party can mute several others. If a party mutes some other party and leaves the conference, the muted party remains muted if more than two participants remain in the conference. If only two participants (including the muted party) remain in the conference, SIP Server drops the conference and establishes a dialog between these two parties, thus unmuting the muted party.

Starting with release 8.1.102.20, you can enable muting in two-way calls by setting the sip-enable-two-party-mute configuration option to true. That way, when a party in a two-way call issues a TSetMuteOn or TSetMuteOff request, the two-way call will be converted to a conference and a Media Server Mute or Unmute command will be issued for the requestor's leg.

Muting one of the conference's participants can be used in parallel with services, such as supervision, listen disconnect, and recording, except when the Customer-on-Hold Privacy is enabled. See also Feature Limitations.

This functionality is provided through TPrivateService requests. The Call Participant Info functionality must be activated, enabling SIP Server to maintain an LCTParty list containing DNs and their locations for all parties present in the call. The LCTParty list is distributed to a T-Library client in EventUserEvent. The OtherDN attribute of the TPrivateService request must contain the party ID received in the LCTParty list.

For all internal conference participants, SIP Server sends EventUserEvent indicating which party was muted. For a disconnected (muted) party, LCTParty[n]_mute is set to on. After a party is unmuted, LCTParty[n]_mute is not present to indicate that the party was unmuted. For the muted/unmuted party, SIP Server generates EventMuteOn/EventMuteOff, respectively.

The T-Library client must include mute/unmute-related parameters in the TPrivateService request that it sends to SIP Server, as follows:

Attribute	Value
PrivateMsgID	Specifies the type of operation to be performed: SIPTS_PRIVATE_SERVICE_MUTE (3027)— Mutes or Unmutes a party in a conference
ThisDN	Specifies the DN on behalf of which the mute/unmute operation is requested. This DN must be registered by the T-Library client.
ConnectionID	References the ID for the call that is currently being muted/unmuted.
Extensions	Specifies key-value pairs used to control the mute/unmute operation: OtherDN—Specifies a DN to be muted or unmuted. Mute—"on" to mute the OtherDN, "off" to unmute it.

SIP Server generates EventPrivateInfo (PrivateMsgID 4029) with the same ReferenceID as the one in the request to indicate that a Mute/Unmute request is accepted. The desktop should rely on the LCTParty EventUserEvent to display the current party state.

Important

This feature depends on support from specific versions of Workspace Desktop or a T-Library client. Consult corresponding documentation for the availability of this new feature in those components.

Mute State Duration

In SIP Server, TSetMuteOn is applied per-call basis. The Mute state is preserved for the duration of the call or until TSetMuteOff is applied. When a new call is created on the same DN, its Mute state is off. When a muted call is released, EventMuteOff is not needed and is not generated.

Examples:

• A main call can be muted, but when a consultation call is created, the consultation call starts in an unmuted state.
• When a two-step transfer or two-step conference is completed, the DN's Mute state will correspond to the Mute state of the main call. The consultation call is released and no EventMuteOff is generated.
• When a call is muted, then parked via the Call Park/Retrieve feature, and then retrieved, that call is reported as a new one and will be unmuted.
• When a Shared Call Appearance (SCA) call is muted, then parked, and then retrieved, that call is reported as a new one and will be unmuted.
• Contrary to the park scenarios, when a call is connected via the Call Divert Destination feature to the new divert destination, SIP Server considers and reports the diversion as part of the same call. Accordingly, no EventReleased is generated and the Mute state is preserved.

Situations When a Mute Operation is Prohibited

SIP Server prohibits Mute operations in the following scenarios:

• When a call is on hold, Mute or UnMute operations are not allowed.
• When a greeting is being played to a party in the call, the Mute operation is not allowed (relates to the case when the sip-two-party-mute-enabled option must be set to true).

Feature Configuration

1. In the [TServer] section of the SIP Server Application, configure the following options:
   • msml-mute-type—Set this option to 1.
   • sip-enable-call-info—Set this option to true.
   • msml-support—Set this option to true.
   • (Optional) sip-enable-two-party-mute—Set this option to true if required.
2. Verify that the sip-enable-call-info-extended is set to true.
3. In the [TServer] section of Trunk DNs (for all trunks between SIP Servers participating in the call flow), set the sip-server-inter-trunk option to true.
4. In the [extrouter] section of the SIP Server Application, set the use-data-from option to current or original.

msml-mute-type

Default Value: 1
Valid Values: 1, 2
Changes Take Effect: Immediately

Specifies the type for muting/unmuting a party in a conference. Type 1 is required to support remote mute functionality in SIP Server. Type 2 is for backward compatibility.

Warning

Use this option only when requested by Genesys Customer Care.

sip-enable-two-party-mute

Setting: TServer section, Application level
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately

When set to true, this option enables muting and unmuting parties in two-way calls via a T-Library request; requires MSML to be enabled.
Note: When set to true, two-party conferences are not be converted to direct calls.

Upgrade Notes

If you run 8.1.101.80 or earlier versions of SIP Server, Genesys recommends the following upgrade procedure:

1. Stop the backup SIP Servers.
2. Upgrade the backup SIP Servers.
3. Promote the backup SIP Servers to primary.
4. Repeat steps 1 to 2 on the backup (formerly primary) SIP Servers.
5. After all SIP Servers in the multi-site configuration are upgraded:
   • Set the sip-enable-call-info option to true.
   • Set the monitor-party-on-hold option to false.
   • Verify that the sip-enable-call-info-extended option is set to true.

Feature Limitations

• If recording is activated on the inbound (customer) trunk, the customer will be recorded even when muted. If recording is activated on the agent leg, this agent will be recorded while muted.
• If DNs with the same names configured on different switches participate in the conference, SIP Server might choose the incorrect party to mute.