Collapse AllExpand All

5.10.1.5. DTMF signaling in a conference concept Previous topic Parent topic Child topic Next topic

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.