XCC - XPhone Call Controller



Please note the codecs supported: Opus, G.711 und G.722 . (see also SIP Gateways)

QoS configuration

QoS (Quality of Service) should be configured for softphone, AnyDevice or conference service connections. With the integrated XCC, this is configured in the operating system as follows.


The QoS configuration of an XCC offloaded on a LINUX satellite is done automatically.

This configuration determines the prioritization with which packets are handled at the network card.

  1. Enter the command gpedit.msc via Start > Run.

  2. Create a new policy (e.g. XC_Softphone) or edit a policy previously created for Softphone under Computer Configuration > Windows Settings > Policy-based QoS:


  3. Guideline Profile tab:


    Specify a unique name for the policy. When specifying the DSCP value, we recommend setting 46. Then press Next.

  4. Tab Application name or URL, enter here under Only applications that are the following executable file: the following path: C:\Program Files\C4B\XPhone Connect Server\XCC\FreeSwitchConsole.exe


    If your XPhone Server is not in the default directory, you must adjust your installation directory here. Press Next.

  5. Tab IP adresses:


    No changes need to be made here. Press Next.

  6. Tab Protokoll and ports:


    For the protocol on which this QoS policy is applied, select UDP. By default, the source port range 30000:33000 is entered here. If you have assigned a different range in the XPhone Connect Server in the XCC settings under System settings > Telephony & Meetings > Telephony > SIP > XCC, you must enter this.


You can use a program for analyzing network communication connections (so-called sniffer), such as Wireshark, to check the settings you have set:


QoS for softphone in WLAN according to IEEE 802.11e (WMM/WME)

The 802.11e extension to WLAN standard 802.11 allows certain data packets in the wireless network to be prioritized (Quality of Service, QoS). It thus represents an important control function for voice transmission in the WLAN (Voice over WLAN, VoWLAN). For technical details, refer to the IEEE 802.11 specification or the summary on Wikipedia.


QoS für VoWLAN steht nur dann zur Verfügung, wenn sowohl der Client im WLAN wie auch der Access Point 802.11e unterstützen.

  • Activate the option QoS according to 802.11e (also known as WMM or WME) for your WLAN interface.

Virtualization host

If you operate the XPhone Connect Server on a Hyper-V image, the following Hyper-V services must be provided for the virtual computer.

Open Server Manager. To do this, enter Start > Run > virtmgmt.msc.

Here you can display all virtual machines under Roles > Hyper-V > Hyper-V Manager. Mark the required machine to display the menu on the right. Under Actions, click Hyper-V Settings. The settings dialog opens:


Under Administration > Integration Services enable the required services see above | You can check whether time synchronization is set correctly by opening the Windows command prompt in the server image with a right-click on Start > Run > cmd or Windows key+R > cmd. | Change to the path C:\Windows\System32 and query the source of the system time with the command w32tm /query /sourceab. If the setting is correct, the result must be VM IC Time Synchronization Provider:


If the message Local CMOS Clock or a name of a NTP host (Network Time Protocol) is displayed, the services provided by the Hyper-V must be checked for correct setting see above.

Client-side QoS Group Policy

In order to be able to give preferential treatment to the audio IP packets in the network, the Windows operating system comes with some options. These are either set directly in the Windows registry or can be distributed via group policy, the last is the procedure recommended by C4B:

  1. Prioritization of data traffic using DSCP

    The priority of outgoing network traffic can be defined via DSCP (Differentiated Services Code Point). According to the description in RFC 2474, DSCP allows values from 0 to 63 in the TOS field (Type of Service) of an IPv4 packet. Network routers use the DSCP value to classify network packets and determine the appropriate queue. A higher value indicates a higher priority of the packet. By default, the Specify DSCP value checkbox is selected and the value is set to 0.

  2. C4B recommends the following settings:

    • DSCP value: 46

    • Anwendungsname: C4B.XPhone.Commander.exe

    • Target port range: 30000:33000

References and sources:

XCC scenarios

The following diagrams provide an overview of possible XCC scenarios. (Please refer to the Server system requirements for the details of the respective configuration).

XPhone Connect Telephony Basic scenario


  • Clients 1-3 are operated as AnyDevice in twinning mode (reachable via Follow-me)

  • Client 4 and 5 operate as AnyDevice Only (route directly from PBX to XCC)

  • Client 1, 2, and 4 use AnyDevice. Client 3 and 5 use XPhone softphone (XPhone softphone is also a kind of AnyDevice).

AnyDevice outbound scenario


  1. An outgoing AnyDevice call is initiated at XPhone Client 1.

  2. The XCC establishes the first call leg in the direction of AnyDevice 1.

  3. If the AnyDevice 1 has answered the call, the XCC initiates the second call leg to the actual call destination (any external subscriber).

  4. As soon as the call destination (any external subscriber) has answered the call, the media (RTP streams) are connected together.

Softphone outbound scenario


  1. At XPhone Client 3 an outgoing softphone call is initiated and thus the first call leg towards XCC is established.

  2. The XCC routes the call to an external destination in this case.

  3. As soon as the call destination has accepted the call, the media (RTP streams) are connected together.

AnyDevice Twinning inbound scenario (FollowMe)


  1. An external caller calls an internal extension which has set a FollowMe call forwarding (CTI call forwarding). The PBX routes accordingly to the XCC.

  2. The incomming cal is sigaled on Client 1.

  3. The XCC knows the AnyDevice from Client 1 and calls it.

  4. As soon as the call was accepted on AnyDevice 1, the media (RTP streams) are connected together.

AnyDevice Only inbound scenario


  1. An external caller calls an internal extension, which is always routed to the XCC on the PBX. - In the default case it is a number band e.g. +4989840987XXX.

  2. The XCC knows the number of Client 4 and signals the call accordingly.

  3. The XCC knows the AnyDevice from client 4 and calls it.

  4. As soon as the call was accepted on AnyDevice 4, the media (RTP streams) are connected together.

AnyDevice twinning softphone inbound scenario (FollowMe)


  1. An external caller calls an internal extension which has set a FollowMe call forwarding (CTI call forwarding). The PBX routes accordingly to the XCC.

  2. The XCC can assign the called number to the Client 3 and calls it.

  3. As soon as the call was accepted on AnyDevice 1, the media (RTP streams) are connected together.

AnyDevice Only softphone inbound scenario


  1. An external caller calls an internal extension, which is always routed to the XCC on the PBX. - In the default case it is a number band e.g. +4989840987XXX.

  2. The XCC can assign the called number to the Client 5 and calls it.

  3. As soon as the call was accepted on AnyDevice 5, the media (RTP streams) are connected together.

Dial-in conference


  1. Client 1 initiate a AnyDevice call to a XCC conference.

  2. The AnyDevice 1 is called by the XCC.

  3. Once the AnyDevice 1 has answered the call, the media is routed to the Conference Room.

  4. Client 3 initiate a softphone call into a XCC conference.

  5. The XCC answers the call and routes the media to the conference room.

  6. An external participant initiates a call into an XCC conference.

  7. The XCC answers the call and routes the media to the conference room.

  8. Client 1 and 3 get the conference signaled as XPhone users.

Call to an XCC waiting field


The waiting field has the distribution strategy Group call. Clients 1 and 3 are logged in as agents.

  1. An external subscriber calls a configured waiting field.

  2. The XCC accepts the call and routes the media to the called waiting area.

  3. The waiting field calls the AnyDevice 1 and signals it at the Client 1.

  4. The waiting field calls the Softphone Client 3.

  5. Client 1 and 3 receive the waiting field signalisation.

  6. Agent 1 (Client 1) accepts the call at AnyDevice 1, thus the media from the external caller is connected to the AnyDevice 1.

XPhone Connect Softphone in a Terminal Server environment


  1. XPhone signalling.

  2. Media XCC <-> XPhone Client (SRTP)

  3. Remote Headset XPhone Client <-> Workstation (e.g. Windows Remote Audio via RDP)


Virtual Follow-Me-User

The Follow-Me function permits the availability of a user under his personal extension (One-Number), regardless of the end device he is currently working with.

In order for this to work, a call to the workstation device (which is available at the personal phone number) must be forwarded to a special XPhone Call Controller (XCC) number. This special number (Follow Me number) is available via an SIP trunk leading to the XCC.

If a user activates the Follow-Me function, his end device shows the Follow-Me number as the forwarding destination. Under normal circumstances, this is unknown to the user and the display is not associated with support on the Follow-Me function.

For this reason, the Follow-Me function can be directed via a virtual port of the gateway (PBX). This port is given the display name “Follow-Me” via the PBX configuration and is directed to the Follow-Me number of the XCC.


At the corresponding SIP gateway on the XPhone Connect Server, the phone number of the virtual user Follow-Me must be set as a value for XccGlobalVirtualFollowMeUserNo in the advanced settings. This parameter permits switching between a virtual port using the Follow-Me function to enable the speaking forwarding destination to be shown.

System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object > Advanced Settings




<Call number of the virtual user>

Furthermore, a virtual participant with the number of the parameter must be configured in the PBX. This virtual participant can then receive a name, e.g. Follow-Me in the PBX -> This name is then shown in the telephone display.


When this parameter is set, the number of the parameter is used for the Follow-Me transfer instead of the central number of the AnyDevice call diversion (configured in the SIP gateway). The virtual participant routes permanently to the central AnyDevice call diversion which, in turn, sends the call to the XPhone Server via SIP trunk

If the user activates the Follow-Me function, his display (depending on the PBX used) shows the term To: Follow-Me. Before that, a number unknown to the user was shown in the display.


Other PBXs on request. If you have already successfully tested this function on another PBX, we would be pleased to receive your feedback.

Redirecting ID Pattern (SIP DIVERSION header)

SIP Diversion Header

Usually applies for all PBXs``^[^<]*<(?:tel|sip):([+]?d+)D+.*$``

It is possible that certain PBX configurations cause the redirecting ID (SIP DIVERSION header) to be transferred for external in E.164 and for internal as an extension. In this case, please proceed as follows:

  1. Open XPhone Connect configuration

  2. System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object > Advanced Settings

  3. Name: XccDiversionPattern

  4. Value: ^[^<]*<(?:tel|sip):(?:[+]4989123456|)(\d{4})\D+.*$

    • 4989123456 must be replaced by a corresponding phone number but without an extension. If the phone number starts with 00, [+] must be replaced by 00.

    • 4 must be replaced by the corresponding phone number length of the internal extensions. The 4 stands for four-digit extensions here. If the extension lengths vary, {4} should be replaced by +.

Clip No Screening

A range of features in connection with AnyDevice are closely linked with the display of phone numbers. Clip no screening enables the company to signal a different caller number externally than its own company number. This enables the XPhone Connect Server to transfer the caller’s number to an AnyDevice user.

This involves the following individual situations:

  1. Callback to your own device when setting up an AnyDevice call.

  2. Display your personal number (One Number) to the called party when a call is set up via AnyDevice.

  3. Show the caller’s number when he calls your personal number and is connected with the AnyDevice via the XPhone Call Controller (XCC).

Case 3 is a special case as a number needs to be signalled which does not originate from the number range of your own voice communication system. Restrictions in the public or private signalling system (PBX) can prevent the XCC setting the number in this case.


Parameters for CLIP configuration for external or internal outbound calls can be set in the advanced line settings.


Setting a sender phone number is influenced in public networks by the Clip No Screening feature. Clip No Screening only works if the following requirements are met:

  • The Clip No Screening feature must have been activated for the company by the landline provider.

  • Clip No Screening must be supported by your voice communication system (PBX).


The GwSetting_caller-id-type parameter determines how the Calling Line Identification (CLI) is transferred via SIP. The following settings can be made via the GwSetting_caller-id-type parameter:

System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object > Advanced Settings





Remote Party-Id (Default) IETF Referenz


P-asserted Identity (see RFC 3325)


The phone number is not transferred to a special SIP element.

As there is no uniform standard for signalling the phone number, it is necessary to set the method anticipated by the voice communication system (PBX) used.

Logs and traces

If the function does not work as anticipated, a trace should be created via the XPhone Connect on-board trace mechanism (see Troubleshooting and Diagnostics) or a Wireshark trace.

Call pick-up from AnyDevice devices

There can be different reasons for a failed call pick-up from AnyDevice in individual cases. Some telephone systems do not support a redirect command (Deflect Call) to ports that are forwarded. This is the case if Follow-Me is activated, for example, and the user wishes to pick up a call from a colleague via XPhone Connect Windows Client. For call pick-up to function despite this, the following configuration steps are necessary:

Configuring the PBX:

A prefix number (e.g. 41) must be configured for the node to the SIP trunk (XPhone Connect Server - XCC) in the PBX.

XPhone Connect Server configuration:

System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object > Advanced Settings

  1. Click Add and select XccGatewayInPrefix.

  2. Add 41 as a value for this name.

  3. Repeat the previous step and select the following name this time: XccUseDirectRedirecting and value 1.

  4. Click Apply and then Save.

System settings > Dialing parameter > Dialing Parameters Object


Do not forget that the length of the internal phone number must be 5 digits for dialling parameters assigned to the SIP Gateway. It consists of the prefix + extension numbers (2 prefix numbers + 3 extension numbers).

Phone number prefix

The XPhone-Call-Controller (XCC) automatically directs inbound calls to a device specified by the user (AnyDevice). To enable the user’s settings to be determined by the Server, it is identified using the phone numbers supplied in the call.

There are two ways to do this:

  1. The gateway (PBX) supplies a so-called redirecting ID, i.e. the number of the device forwarding a call. This corresponds with the number of the workstation telephone whose number is stored in the user properties.

  2. If the gateway does not supply the redirecting ID, the so-called Called Party ID is used. The numbers of the AnyDevice end devices in the XCC are identical to the extensions for the respective users in the voice gateway. The XccGatewayInPrefix is used to make AnyDevices unique in the voice gateway number plan.

The XccGatewayInPrefix defines a phone number prefix which the gateway positions before the phone number forwarded to the XPhone-Call-Controller. The XCC removes the prefix and determines which user is affected on the basis of the remaining phone number. The gateway uses the prefix to configure the routing to the XCC in such a way that calls to the AnyDevice are directed to the SIP trunk to the Call-Controller.


In order for the value XccGatewayInPrefix to take effect, the option Uniform phone number… must not be active in the SIP gateway settings under AnyDevice/Softphone and the Phone number for redirection must be empty here.


Sample configuration for the user with the number 100 and the prefix 6 for all other employees:

System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object > Advanced Settings





  • Routing in Gateway = 6 leads to the SIP trunk of the XCC.

  • Call to 6100 = Call is routed to the AnyDevice of the user with the number 100.

Even if the gateway provides a redirecting ID, the XccGatewayInPrefix may need to be specified along with the XccUseDirectRedirecting parameter.


In the case of the dialling parameters assigned to the telefony and SIP gateway, it must be ensured that the length of the internal number may need to be modified, e.g. to 5 digits. It consists of the prefix + extension numbers (2 prefix numbers + 3 extension numbers). See System settings > Dialing parameter > Dialling parameter object.

Redirect/deflect feature

This parameter is required if the redirect/deflect function is run via call control interface (e.g. TAPI/CSTA) on a workstation device where the FollowMe transfer is activated. A range of voice gateways does not permit a forwarded port for call deflection and acknowledge this request as an error.


If the call deflection destination is an AnyDevice device (e.g. where the Follow-Me function is active), the XPhone Connect Server can also reach the AnyDevice device via the XccGatewayInPrefix .

System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object > Advanced Settings




1: The setting should be 1 if this mode is to be activated.

Linked PBX systems


These instructions are based on experience gained from connecting various systems. Depending on the existing environment, there may be differences in the implementation.


You are using a PBX that serves multiple sites or manages multiple trunk lines with different exchange numbers. A connection with only one SIP trunk for the XPhone Call Controller (XCC) to the telephone system is desired because the server and main system are connected in a central data center.


The XCC is connected to the PBX via a SIP trunk. The configuration on the XPhone Connect server as well as the user configuration is simplified by this setup. The configuration is simplified overall because a separate SIP trunk is not required for each gateway.





  • The PBX must be interconnected with the various sites so that SIP messages are transmitted from the master node to the connected XCC SIP trunk.

  • The network must have QoS policies so that the RTP packets are prioritized.

  • Routing from the sub-locations (gateway & extension) must allow a direct connection to the XPhone Connect server. Here, it must be taken into account how the PBX handles RTP streams and whether centralized or decentralized streaming is used.

  • The transmission of call numbers from the PBX master to the XCC SIP trunk must be in E.164 format to ensure unique call number identification. This ensures that the correct AnyDevice user can be determined.

XPhone Connect configuration

Dialling parameter

A separate dialing parameter should be created for the networked system for each site or trunk. It is also advisable to differentiate between SIP and CTI dialing parameters. This means that different dialing parameters or special configurations can be implemented.


Configure a SIP trunk on the XPhone Server

The SIP trunk on the XPhone Connect Server is set up with the appropriate connection data:

  • The IP address of the XPhone Connect Server is used for the local gateway.

  • The IP address of the master PBX is entered in the remote gateway field.


The AnyDevice phone number must be stored in E.164 format. In this example, the phone number +498912345815 is used. For the conference server, only the extension number (816) may still be used!


Add dialing parameter in SIP trunk

To be able to provide users with AnyDevice lines, the correct dialing parameter must be stored on the SIP trunk.

  • Select the SIP trunk.

  • Click Create Lines, to add further parameters.


Click Add to create a new phone number range.


Set the value * for the from and to fields to include any phone number of the location.

A corresponding SIP dialing parameter of the other sites must be selected as dialing parameter.


Save the phone number range and add more as well if necessary.


When all dialing parameters of the sites have been added, end the creation via Close! The line generation must NOT be executed!


Add AnyDevice Line to the user

In the user administration, users receive an AnyDevice line via AnyDevice Wizard. For this, the differentiation applies whether the user additionally uses a CTI line or not (AnyDevice Only).

The corresponding SIP trunk is used as the trunk.

CSTA special dialing paramter configuration

For further locations (e.g., Berlin and Hamburg), special configurations must be performed in the dialing parameters. The AnyDevice number from the XCC SIP trunk must be edited for the CSTA dialing parameter. Call forwarding is usually only performed on the extension number, so a PhoneToDisplay rule must be created that adapts the extension number to the E.164 format.

  • Open the tool Dialing parameter special configuration via the XPhone connect server Manager (Tools).

  • Log in with the administrator access of the XPhone Connect Server (default: admin/admin , but you should change this login data!).

  • Select the appropriate dialing parameter for the CTI connection (here: Berlin location).

  • Add a new entry via the New item.


  • Select PhoneToDisplay.

  • Set for in Value 1 your value for the extention of the AnyDevice number.

  • For value 2, enter the AnyDevice call number of the main site in E.164 format.

  • Click OK.


  • Finally set the DefaultPhoneToDisplay settings via the dial parameter.

  • To do this, use the E.164 format so that the previously set dialing parameter takes effect.

  • Click OK.

These steps must be carried out for all other dialing parameters (e.g. Hamburg). For example, the configuration for the Berlin and Hamburg locations looks like this:



Further dialling parameter settings

If the PBX expects all phone numbers via the SIP trunk - even for internal dialing - in E.164 format, the following values must be set.

Dialing parameters for the SIP connection

In the dialing parameter for the SIP connection (e.g.: Berlin_SIP or Hamburg_SIP), the Flags attribute must be set with the value 304. The value results from the addition of the value 48 (external call number in the format +49…) and the value 256 (internal call number in the format +49….). Thus, for outgoing calls from the XCC SIP trunk to the PBX, the To headers are signaled in E.164. This step must then be performed for all other SIP dialing parameters of the connected sites, including the main site.


Adaptation of the atlas.xml

If the Flags attribute is set to 304 in the dialing parameters, the atlas.xml must be used to deactivate the checking of the internal call number when creating the line for AnyDevice lines.

The following value must therefore be added to the atlas.xml under Configuration:

<Telephony PBXAutoConfig="64"/>



In order for the change to take effect in atlas.xml, the server services must be restarted.

Dialing parameter special configuration

For dialing parameters of the SIP trunk, the DefaultPhoneToDisplayFormat attributes should also be set to the value 64. This means that all phone numbers are displayed in E.164 format. This adjustment should be made to all dialing parameters that are required for the AnyDevice connection.



By default, the XPhone Call Controller expects DTMF according to RFC 2833 (RTP event in the inbound stream).

DTMF In-band

It may happen (especially if the PBX is doing DMC) that there is no way to influence the behavior! In this case, the following settings are necessary:

System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object > Advanced Settings





Configure external media

For the feature Softphone Mobile and Payload Separation the XCC must be configured for external media. Here you can find out what has to be done for this:

  • The XCC is configured with at least one functional SIP Gateway (PBX or SBC).

  • The XCC must be able to reach an external STUN server to request its external IP.

    • External accessibility for audio media from XCC must not change arbitrarily.

  • Navigate to System settings > Telephony & Meetings > Telephony > SIP > XCC.

    • For Private IP Address Ranges, enter all networks so that the XCC can make a preferred selection of which path the audio media (RTP) should take.

      • Enter all internally routed networks.

    • The RTP port range can be configured here.

      • The firewall or NAT router must be configured accordingly so that the above ports of the XCC can be reached from the Internet.

      • Different mapping of external ports to internal XCC ports is not possible.

      • After that, the XCC must be terminated and restarted.


      Alternatively, a TURN server can be used for the audio media streams. See: Media data streams and signaling.

    • If the XCC is behind a restrictive NAT, it may be necessary to enable hole punching.

      • This hole punching is used for each connection that is to be used inbound.


      This setting should not be necessary and the infrastructure/firewalls should allow incoming RTP connections.

  • At least one functional STUN server must be configured under System settings > Telephony & Meetings > Network.

    • You can test the function of the STUN server by using the Detect NAT Type button and thereby get the information behind what kind of NAT Type the XCC is working.

  • Under System settings > Telephony & Meetings > Telephony > SIP > SIP Gateway object, for using Softphone Mobile or Payload Separation UseSTUN Server must be enabled.

    • If one or more network adapters are selected (only required for Windows XCC), a windump trace is created when XCC logging with debug messages is activated, which contains the negotiation of the audio media.


XCC Troubleshooting - Advanced settings

When connecting the telephone system, advanced settings may be required in the SIP trunk setup for the customer-specific configuration of the PBX. In order to optimally support the connection of the PBX, certain parameters can be adapted for the SIP trunk.

To do this, open the corresponding SIP trunk under System settings > Telephony & Meetings > Telephony > SIP and switch to the advanced settings tab. The following parameters can be set to adjust the call number signaling:

  • XccDiversionHeaderFormat

  • XccClipNoScreeningFormat

  • XccFromHeaderAsCLIP

  • XccForceSip180Ringing

  • XccUseLocalIpAsFromDomain

  • ConferenceUseInBandDtmf


XccDiversionHeaderFormat defines in which format the phone number of the original redirected destination is expected. The default value is always set according to the selected PBX system. If there is a deviation here, the value can be adjusted.


In the default settings, the XccDiversionHeader is expected as an extension, the telephone system sends this value in E.164 format.

In this case, the XccDiversionHeaderFormat must be adjusted with the value 1.


For call number signaling, the call number of the original caller is transmitted in the SIP header with P-Asserted-Identity or Remote-Party ID. If the PBX in use expects the phone numbers in one of the formats mentioned below, the corresponding format can be set via the parameter XccClipNoScreeningFormat.

Possible valus








International without 00 (special in some Unify systems)


The parameter XccFromHeaderAsCLIP solves the problem that with an AnyDevice FollowMe Call the own phone number is shown as caller in the call journal. This can be the case, for example, if the PBX transfers the wrong value in the Remote Party ID or P Asserted Identity header, as is currently the case with OpenScape Business. This display error is corrected on the XPhone Connect Server by using the From header of the first call leg as the CLIP.

In order for the parameter to take effect, the value True must be set for XccFromHeaderAsCLIP on the corresponding SIP gateway.


The parameter XccForceSip180Ringing forces SIP 180 Ringing to be sent on the caller leg for an inbound AnyDevice call, even if the telephone system is working with a Session Progress.

In order for the parameter to take effect, the value True must be set for XccForceSip180Ringing on the corresponding SIP gateway.


The XccUseLocalIpAsFromDomain parameter fixes the problem that the Alcatel OXE PBX disconnects FollowMe calls from GAP or Softphone devices.

In order for the parameter to take effect, the value True must be set for XccUseLocalIpAsFromDomain on the corresponding SIP gateway.


This parameter causes DTMF tones, which are transmitted in the RTP stream, to be recognized for user registration in the conference room. This means that entering the conference PIN is recognized and the caller can log in.

In order for the parameter to take effect, the value True must be set for ConferenceUseInBandDtmf on the corresponding SIP gateway.

Have you found an mistake on this page?

Please send us a hint about this error by mail to doku@c4b.de. Thank you very much!