For conference states, DTMF signaling is allowed if it is requested
for at least one of the conference members (except the member who pressed
the key). Both analog devices, digital devices, and external partners
are able to receive DTMF signaling while in conference. The DTMF signal
will be generated by each member of the conference by itself.
To prevent a local partner from hearing DTMF signals while in conference,
the station basis flag "Block DTMF in Conference" should be configured.
With this flag, the local partner will not hear a local DTMF tone, remaining
connected in the conference during the signaling process. This flag should
block the DTMF signaling only when it is generated internally, by a local
conference member.
The internal DTMF conference signaling will be provided in a conference
(limited to 4 conference members).
By default, all external partners of a DTMF conference should be able
to hear DTMF automatically, also when they do not require to hear DTMF
tone.
In the DTMF conference, each local analog, digital, and external partner
should be responsible for the DTMF conversion itself. In the same way
the flag DHPAR=DTMFST and DTMFCTRD=YES will set this requirement that
the conference member device that has the DTMF flag.
IMPORTANT:
Attendant devices and functional devices will
not be able to hear DTMF digits in a conference because the DTMF in conference
feature shall cover ACD scenarios and neither attendant devices, nor
functional devices can be ACD agents.
The following trunks will support DTMF dialing in conference scenarios:
- Analog trunk with signaling type DP (dial pulse)
- Analog trunk with signaling type DTMF
- Analog trunk with signaling type MFCR2
- Digital trunk with signaling type DP - dial pulse
- Digital trunk with signaling type DTMF
- Digital trunk with signaling type MFCR2
- Cornet trunk - ISDN
- PRI trunk
- Ground Start trunk
- E+M trunk
The following device/signaling types will NOT support DTMF dialing in conference
scenarios:
- Functional devices (because it cannot become an agent)
- Attendant (because it cannot become an agent or supervisor).
- other trunks not mentioned above, such as cornet analog trunks, will not be
implemented.
Notes:
- If in the history of a conference at least one member required DTMF
signaling, for the NW party this conference will require DTMF signaling.
This will occur because the NW party is not informed that a local conference
member disconnected (e.g. only this local conference member, which disconnects,
requires DTMF in this conference). However, once the conference is removed
(for example, the conference resources are released and the connection
reduces to two parties), the NW is informed.
- If in the history of a conference (with local, and NW orphan members)
no member had required DTMF signaling, and in this scenario a new local
member which requires DTMF is added to this conference, the NW orphan
member(s) will not be informed that at least one member of this conference
requires DTMF.
- The case where the single remote party connected to the conference
via NW makes a conference in their node, thus having two conferences
connected via NW trunk will be handled like specified in the NW Conference
and Station Conference Features. They state that when two conferences
are linked via a NW connection, the user interface shall operate as two
independent conferences. In this case, Call Processing for the DTMF dialing
feature will transport the DTMF feature indicator when only one side
is in a conference state.