Vega FAQ
Cannot make outbound Calls from a POTS handset connected to an FXS port?
When I try to make a call I get a cleardown code which I do not understand?
What do I do if, during installation, the PBX reports RAI and layer 1 does not come up?
My H.323 Vega does not register with the gatekeeper at power on or reboot
...
| Panel | ||
|---|---|---|
| ||
THIS DOCUMENT DESCRIBES A NUMBER OF PROBLEMS THAT MAY BE ENCOUNTERED AND METHODS TO WORK AROUND THEM. |
Telephony Questions
What are the differences between FXS ports and FXO ports?
Vega FXS ports are analogue loop start interfaces. FXS ports can have telephones plugged into them; they can also have analogue trunk interfaces of PBXs connected to them.
Vega FXO ports are analogue loop start interfaces. FXO ports can plug into PSTN lines and extension port interfaces of a PBX
For further information about FXS and FXO operation, see Information Note 'IN_11 FXS and FXO useful information' available on the wiki.sangoma.com web site and also the 'VegaStream Scenarios' document available on request.
Cannot make outbound Calls from a POTS handset connected to an FXS port?
If when dialing digits from a POTS handset connected to an FXS Vega you still hear dial tone this will be due to the DTMF digits being dialed not being detected by the gateway, to resolve this change the POTS digital rx gain.
...
Depending on the POTS handset or line itself you may need to try several settings before detection of the dialed digits is reliable. The range of values to test the digital rx gain setting is from -2 to +5 in increments of 1, be aware that these settings effect the audio levels as well as DTMF detection, and entering the highest value will often result in audio being clipped.
On a BRI unit I am getting regular link down, link up messages in the event log, and the BRI layer 1 LED flashes?
Many Basic Rate ISDN trunks take layer 2 down when the line is not in use, only bringing up layer 2 when a call is to be made.
By default the Vega automatically tries to reinstate layer 2 immediately it sees layer 2 going down. This results in later 2 being removed, re-instated, and removed again on a regular basis. This can be observed by seeing regular link-down and link-up messages in the event log.
To allow layer 2 to be taken down between calls and only brought up for the duration of the calls, on the command line interface type:
...
| Code Block |
|---|
set _advanced.isdn.restart_l2_after_disc=0 |
When I try to make a call I get a cleardown code which I do not understand?
Call cleardown cause codes are documented on the wiki.sangoma.com web site in the Documentation > Technical documentation > Other useful documents > 'Q850 Cleardown cause codes’ document. This document expands upon the standard Q.850 document with specific reasons why in a Vega VoIP environment you get specific call cleardown reasons.
Why do I not get a DISPLAY name on a TE to NT link?
The Q.931 specification states that DISPLAY is only valid from NT to TE. It is not valid TE to NT. The Vega gateway abides by this specification.
Why does my ISDN call not work for ISDN to ISDN calls?
n ISDN SETUP messages, as well as the dialled number and possibly the Calling Party Number, there can be other information carried in other 'IEs' - Information Elements. Although the Vega passes some IEs through by default, others get dropped. To enable specific IEs to be passed by the Vega it must be configured to 'tunnel' these IEs through.
To enable tunnelling of IEs:
...
Multiple IEs can be tunnelled by setting IEs_to_tunnel to a comma separated list of mie_ids
To determine which, if any, IEs need to be tunnelled use the ISDN trace capability in the Vega and look at the SETUP message coming in and the SETUP message being sent out. the IE numbers are marked 'mie_id'.
For further information about IE tunnelling see the Primer
What do I do if, during installation, the PBX reports RAI and layer 1 does not come up?
RAI - Remote Alarm Indication and layer 1 not coming up can be an indication that the E1 Vega has the wrong setting for PCM30 / CRC4. On the web browser under the DSL pages look for the framing configuration entry and change it between PCM30 and CRC4.
H.323 Questions
My H.323 Vega does not register with the gatekeeper at power on or reboot
For an H.323 Vega to initiate registration the Vega needs to be in gatekeeper mode and its H.323 Alias needs to be set to something other than NULL. On the H.323 page on the web browser, ensure that gatekeeper mode is selected (at the top of the page it says Current Mode: Gatekeeper, and the change mode button is labeled ‘Standalone Mode’). At the bottom of the page in the section labeled H.323 Gatekeeper Terminal Alias ensure that there is at least one entry where the name is not NULL.
SIP Questions
My SIP Registration is failing - why?
When attempting to register with a registrar, there are a number of error messages that may be returned. These include Unauthorised and Declined.
...
| Info |
|---|
Example REGISTER sip:211.155.123.3:5060 SIP/2.0
REGISTER sip:http://callmehere.com :5060 SIP/2.0 |
I get no ringback tone when calling an FXS Vega gateway even though the phone is ringing - why?
In VoIP systems, ringback tone (the ringing tone you hear in your ear when you make a call) may be sourced by the local handset making the call, or by the destination VoIP device generating the tone and sending it as media over the VoIP link for the calling party to hear.
...
For information on ringback tone generation on ISDN and CAS systems, see 'ISDN SIP parameters for ringback generation to the VoIP interface' in the Vega primer.
I am sending RFC2833 messages to the Vega but it is not generating any tones?
RFC2833 messages are sent as RTP messages. Vega gateways expect to see the RFC2833 messages at roughly the same cadence rate as the usual media RTP packets. At the end of the tone, the 'end' message is usually replicated 3 times (to ensure that the message gets through, even if 1 or 2 packets are lost.
...
RFC 2833 messages also contain a volume value. The specification defines that a value 0 to 63 may be defined ... 0 represents 0 dbm0 and 63 represents -63 dbm0. Values above -36dbm0 must be detected as a valid tone, and values below -55dbm0 must be rejected. Therefore to ensure that DTMF tones are detected properly make sure that the volume value is 0 to 35.
How Can I Force 180's To Be Sent?
You can do this by simply running the commands below. Just go to "Expert Config->Advanced->CLI Command".
...
Once the commands are ran 180's should always be sent out from the Vega.
Instead of receiving Calling Party Number, I'm receiving Auth Name/Trunk Name on SIP end?
The most common reason for this is in SIP profile “From Header” field is not correctly setup.
...
This should resolve your issue, if not please contact Sangoma Technical Support.
FTP, TFTP and upgrade Questions
I get a message "cannot connect to TFTP server"?
For example when trying to put config data onto a tftp server the following sequence occurs:
...
Check that the Vega can ping the tftp server. If it can, ensure that the tftp server is operational (e.g. use another client to put and get files to/from the server). If not, then ensure that the tftp server is designed to operate on the operating system that it is being run on, for examples Windows 95/98 software often does not run properly on Windows 2000/NT. There are a number of TFTP servers readily available on the web, for example PumpKIN or TFTP Turbo.
I get a message "error - not a VegaStream file" when upgrading my system?
For example when carrying out an upgrade the following sequence occurs:
...
Check that the .abs file is not corrupted. It may be corrupted by loading the .abs file onto the server in binary mode - you need to copy it onto the server using ASCII mode copy. Also on UNIX systems you may have to run the dos2unix application on the file on the UNIX server to format it in the correct manner (big endian / little endian) before attempting the download.
You will also receive this message if you try to load the wrong type of code file onto a Vega gateway, e.g. a Vega 100 set of code onto a Vega 400.
Vega stops downloading the firmware image in the middle of the upgrade?
The TFTP protocol is quite sensitive to network issues. The best way to upgrade is to have the TFTP server and the Vega on the same local subnet, preferably connected to the same hub or switch. If this is not possible, use FTP rather than TFTP to do the upgrade as this handles resending data packets that may get dropped.
How do I backup / restore my configuration?
The commands PUT and GET can be used to export and import configuration data to/from a TFTP or FTP server. The command formats are:
...
… these commands read a text config file from the (T)FTP server into the Vega. N.B. take care – ‘get’ overwrites parameters that you may have already set up.
The file format generated by ‘PUT’ and read in by ‘GET’ is in the form of a script using cp (change path) and set (set value) commands.GET effectively puts the contents of the text file into the keyboard buffer of the Vega as though it had been typed in at a keyboard. Comment lines start with a ';' character and the whole line is ignored when the script is read in.
Dial Planner Questions
White List
Although in white list dial plan entries the Vega is looking at Callers’ IP addresses and Callers’ telephone numbers, rather than using TELC and TAC in the dial plan entries, for TELC use TEL and for TAC use TA.
N.B. This is for white lists only, dial plan entries use TEL:, TELC:, TA and TAC: as expected.
Assigning FXO Ports DID's and Groups
Question: How can I add DID's to each analog line? Also can I group two or more lines to a single DID?
...
Example #3 - Source: IF:020[1-5] Destination: IF:9901,TEL:9054741990
Explanation - This assigns "9054741990" to ports 1 to 5. Note ports 2 and 4 are included.
...
For the calls from SIP->FXO you can use the following example. It is important to note that the DID is being sent in the from user part of the sip message here. This is how the correct port is determined and the reason for the TELC token in the source field.
Example
Source: IF:9901,TELC:9054741990,TEL:<.*> Destination: IF:201,TEL<1>
Source: IF:9901,TELC:9054741991,TEL:<.*> Destination: IF:202,TEL<1>
Source: IF:9901,TELC:9054741992,TEL:<.*> Destination: IF:203,TEL<1>
Source: IF:9901,TELC:9054741993,TEL:<.*> Destination: IF:204,TEL<1>
Source: IF:9901,TELC:9054741994,TEL:<.*> Destination: IF:205,TEL<1>
Source: IF:9901,TELC:9054741995,TEL:<.*> Destination: IF:206,TEL<1>
Source: IF:9901,TELC:9054741996,TEL:<.*> Destination: IF:207,TEL<1>
Source: IF:9901,TELC:9054741997,TEL:<.*> Destination: IF:208,TEL<1>
...
| Info |
|---|
Example Source: IF:9901,TELC:9054741990, TEL:<.*> Destination: IF:0600,TEL<1> |
Fax Questions
Fax calls work to standard fax machines, but are intermittent in even starting to send faxes if the destination fax machine is a combined fax / phone / answering machine
With standard fax only fax machines, as soon as they receive a call they answer it and play a tone (known as the CED tone) to indicate to the calling party that it is a fax machine they have reached, and that it is ready to accept the fax data.
On combined fax / phone / answering machine systems the receiving device listens for a tone from the calling fax machine (known as the CNG tone) to determine whether the call is a voice or fax call; only once it has heard the CNG tone will it respond with the CED tone. The challenge with this is that the receiving phone must detect the CNG tone. Like DTMF tones, the more the compression applied on the VoIP link, the less likely tones are to be passed through in a pure enough manner to be detected at the far end. Therefore if high compression is used on the VoIP link, the far end may not detect the CNG tone and so the system may not switch into fax receiving mode. (This is indicated by the call being answered, but the handset continuing to ring until is switched to voice-mail.)
To fix this, use a codec that applies less compression, e.g. instead of using G.7231 use G.729 or G.711.
T.38 fax does not work reliably with Cisco VoIP gateways
By default Vega gateways expect to see T.30 / T.38 messages arriving in sequence. With certain gateways (e.g. Cisco) the messages are not always sent out sequentially. By enabling fax buffering the Vega can handle this; it re-orders the T.30 / T.38 messages into sequential order as it puts them in the buffer.
To enable fax buffering:
...
| Code Block |
|---|
set _advanced.dsp.buffering.fax.depth=100 set _advanced.dsp.buffering.fax.enable=1 |
Maintenance Questions
What is the latest firmware and where can I get it from?
Typically you should only upgrade your Vega after discussion with VegaStream or your authorised VegaStream reseller. Vega firmware, however, is available on the firmware page of the wiki.sangoma.com web site.
In a 'Log Display On', how do I identify which DSL the ISDN messages refer to?
In log display on output there is an ‘R/C’ identifier for each event logged. For ISDN event log messages, the digits following the ‘C’ part of the identifier are the channel number:
LOG: 01/10/2004 14:08:34.697 ISDN (I)R01C26 incoming
call ref [f10f033b] srce=TEL:1842851736 [0]
The ‘C’, channel numbers can be decoded to identify the DSL to which this log message refers.
...
For E1 systems, ‘C’ values ending in 0 (timeslots 0 and 16) are used for signalling and link synchronisation and so will not be seen in log display on traces.
For T1 PRI systems ‘C’ values of 17, 2f, 47 and 5f are used for signalling and link synchronisation and so will not be seen in log display on traces.
In RTP, what values should I expect in Mark, Seq and Time?
The ‘Mark’ flag is an indicator that this is the first packet after a gap in audio. This may be the very first packet of audio for the call, or it may be the first packet after a ‘silence supression’ gap.
‘Seq’ is a sequence number. This increments by 1 in every RTP packet carrying audio data. If there is a ‘silence supression’ gap, the first packet after the gap has a sequence value 1 higher than the last packet before the gap. At the start of a call Seq may start at any value. There is no correlation between Seq numbers in outbound RTP and Seq numbers in inbound RTP.
‘Time’ is the send time of the RTP packet and is measured in 1/8th seconds (125ms periods). At the start of a call ‘Time’ may start at any value. There is no correlation between the starting ‘Time’ value in outbound RTP and the starting ‘Time’ value in inbound RTP.
3rd party interop Questions
Asterisk interop
Asterisk is a proxy toolkit … in its raw form, customers have told us that it typically takes about 6 months development to get it into a production usable system. Now however there are front ends like ‘Trix Box’ (used to be called ‘Asterisk at home’) that mean there is a nice web configuration for Asterisk and it can be used by the naïve user in a much shorter time.
...
When using the Trix Box with FXS Vega gateways, the Vega is typically operating as a bank of IP phones. The Trix Box should configure the Vega extensions as IP phone extensions and the Vega should be configured with one registration and 1 authentication per interface (treat it as multiple individual telephones).
AYC interop - Media
AYC IP PBXs do not like the Vega having Silence suppression enabled (VADU enabled). If VADU is enabled it can affect the play-out quality of (for example) IVR prompts - this affect is worsened under heavy load.
Always disabled VADU on all codecs used (typically G.729 and G.711)
On the media page, on the Voice profile set VADU Enabled = 0 (untick)
Brekeke Ondo
To implement a simple proxy that will allow Vega gateways and other devices to register and call each other, follow the procedure below:
...
Configure the Vega using the initial configuration guide, entering the IP address of the Brekeke PC for proxy, registrar and local domain.
BroadSoft interop
For configuration details for Vega gateways working with BroadSoft, see the interop documents on the Step by Step page of wiki.sangoma.com.
NOTE ... on the BroadWorks server you have to configure the type of endpoint it is connecting to. Selection of 'Vega 50' as the endpoint is designed for FXS Vega gateways that are going to send hookflash and DTMF messages (via info messages) to the BroadWorks server to initiate call transfer, call conferencing etc. If you wish the Vega FXS to be able to initiate call transfers using its built in supplementary services functionality and using SIP REFER messages, do not select 'Vega 50' on BroadWorks as in this mode BroadWorks will not accept REFER messages from the Vega.
- For FXS, select one of the options like 'Generic SIP STD (proxy addr)'
- For trunking gateways (Vega 400, Vega 50 BRI, and Vega FXO) select one of the options like 'Generic Trusted/Registered IP-PBX'
Cisco interop
For configuration details for Vega gateways working with Cisco gateways (especially the AS5300) see the interop document on the Step by Step page of wiki.sangoma.com.
This document contains both Vega and Cisco parameter configuration information and pinout details of both manufacturer's gateways.
Cisco Call Manager - How do I get a Vega to advertise its prefixes
In H.323, as part of gatekeeper registration, a gateway registers the telephone number prefixes that it can handle for calls from VoIP to telephony. Vega gateways register the prefixes defined in their dial plans for dial plans whose source interface is IF:05 – prefixes are indicated by the dial plan telephone number ending with ‘.*
Cisco Call Manager however requires that each prefix entry is terminated by a # character. Extra dial plan entries are therefore required in the Vega to provide the prefix information to the Call Manager in the format it wishes to see them.
For example, for handling calls to telephony numbers starting with 404, 1344 and 506:
For routing calls, the three dial plan source expressions are:
...
| Code Block |
|---|
IF:05,TEL:404#.* IF:05,TEL:1344#.* IF:05,TEL:506#.* |
Cisco - unexpected cleardown reasons
Call cleardown cause codes are documented on the wiki.sangoma.com web site in the Documentation > Technical documentation > Other useful documents > ‘Q850 Cleardown cause codes’ document.
Some cause codes which have been specifically seen when the Vega is interworking with Vega gateways are documented here:
cleardown cause 44 or 65
When making a call from a Vega to a Cisco, disconnect 44 and 65 can indicate that the bearer capability is not configured correctly on the Cisco gateway. Cisco have documentation on their site at http://www.cisco.com/warp/public/788/signalling/h323-isdn-callfailure.html.
...
| Code Block |
|---|
set .h323.use_h245_tunnel=1 save reboot system |
Microsoft LCS (Live Communications Server)
Note 1. Microsoft Live Communication Server does not support the Q.850 header in SIP messages, and doesn't handle its presence very well either.
...
Note 3. VegaStream firmware before R080S010 does not support SIP messages where the header 'Contenet-Length:' is fully capitalised (i.e. 'CONTENT-LENGTH:'). Some versions of LCS send the fully capitalised version. If your version of LCS does send the fully capitalised version, ensure that you upgrade your Vega firmware to a build >= R080S010. (Note that if 'CONTENT-LENGTH:' is capitalised the incoming SIP message is not even shown in 'sip monitor on' as the Vega cannot detect the end of the SIP message (as it does not know the content length).
Microsoft NetMeeting
Microsoft Netmeeting is an H.323 endpoint, so ensure that you have the correct firmware running in the Vega.
Ensure that the Vega is configured such that it does not include T.38 in its faststart capabilities (as Netmeeting existed before T.38 did!).
No ringback? - Netmeeting sets the call bearer capability to “unrestricted digital”. If this is passed from the Vega gateway into the ISDN Network, the ISDN will not report back any ringing state (as that is a ‘speech’ bearer capability function) so the Netmeeting caller will hear no ringback.
When using a Vega 400, Vega 100 and Vega 50 BRI >= R7, where the VoIP bearer capability is passed through, you may wish to override the bearer capability received on the VoIP interface and force it to ‘speech’ when presented to the ISDN. This is accomplished by configuring setup mapping bearer capability to speech.
Netmeeting requires that a telephone number is specified in the call setup (even though it may be the only SoftPhone running at that IP address) so ensure that the TEL: token is defined in the Vega gateway’s destination dial plan rule.
QuesCom interop
Vega gateways usually use a 183 Progress message rather than a 180 Ringing message in SIP to indicate that the call is in an alerting state as the 183 allows the Vega to pass through any in-band media that may be present , e.g. instead of ringing tone the Network might provide an announcement like "the number you have dialled has now changed to ...."
...
[Observed with QuesCom Q400 running software IAD4.20B029P005]
Rostrvm interop - Media
The recommended DSP configuration for inter-working with Rostrvm is:
On the Vega's web browser DSP page, set the Voice profile for the codec as follows:
...
Rostrvm does not support G711 A law - ensure that G711 A law is not included in the Vega media capability sets. If the Vega were to select A law then although the SIP signalling would complete correctly no audio would be heard.
Firewalls and NAT Questions
Cisco PIX - Vega sdp is not correctly translated by Cisco's ALG resulting in no audio being received from the public network into the private network
The Cisco PIX NAT / Firewall has an ALG (Application Layer Gateway) that is supposed to be able to correctly translate SIP messages as they traverse the firewall. If it fails to translate the SDP element, no audio will be able to traverse the firewall from outside to inside.
In Cisco code 6.3(3), the ALG fails to translate the SDP if the 'c=' line is in the media description section of the SDP.
SIP standards allow the 'c=' (Content-Type) to be in the main part of the SDP, the media section of the SDP, or both. (If both, the one in the media section overrides the other.)
For Cisco PIX code 6.3(3) and before (and maybe after) the 'c=' must only be in the main part of the SDP if it is to correctly translate the SDP.
Vega gateways can be configured to put the 'c=' line in the main part of the SDP (above the media section) by performing the following commands:
...
| Code Block |
|---|
set _advanced.sip.sdp.sess_desc_connection=1 save apply |
Web browser does not work properly through a firewall / through a VPN tunnel
The Cisco PIX NAT / Firewall has an ALG (Application Layer Gateway) that is supposed to be able to correctly translate SIP messages as they traverse the firewall. If it fails to translate the SDP element, no audio will be able to traverse the firewall from outside to inside.
In Cisco code 6.3(3), the ALG fails to translate the SDP if the 'c=' line is in the media description section of the SDP.
SIP standards allow the 'c=' (Content-Type) to be in the main part of the SDP, the media section of the SDP, or both. (If both, the one in the media section overrides the other.)
For Cisco PIX code 6.3(3) and before (and maybe after) the 'c=' must only be in the main part of the SDP if it is to correctly translate the SDP.
Vega gateways can be configured to put the 'c=' line in the main part of the SDP (above the media section) by performing the following commands:
...
| Code Block |
|---|
set _advanced.sip.sdp.sess_desc_connection=1 save apply |
Debugging Questions
How do I collect an ISDN trace if I only have web access to my Vega (no telnet or serial access)?
Although easier for most configuration and management tasks, the web browser is unable to display dynamically changing information like logging or debug output.
A technique to capture and display Debug information without producing dynamic output, for use on the web browser, is as follows
Using the CLI Command box on the Advanced page of the web browser,
- Debug commands can be set up
- The Vega can be commanded to store the debug output to an internal buffer
- The Vega can be commanded to dump the internal buffer to the web browser display
To capture and display SIP, router and ISDN debug info, use the following commands:
...
For details about decoding the ISDN trace, see the 'ISDN Trace' document on the Technical documentation page of wiki.sangoma.com.
When I dial on my phone connected to an FXS port dial tone stays on the line and DTMF is never detected?
This occurs because the tone is very low volume. The fix for this is to run the CLI command "set ._advanced.pots.fxs.1.digital_rx_gain=3" in Expert Config -> Advanced->CLI Command. This will boost the volume. Now if this doesn't work then simply increase the value by 3 each time. Also note a "apply" command is required to make the change live and a "save" is required to keep the command option set after a reboot/power loss.
PSTN Config: Digital
Why Is There No Ringing When I Call In The PRI?
This is most likely because the Vega is sending the call to SIP and the SIP side has sent back a 180 which tells the Vega that it needs to generate the ring tone. Now in most cases this is fine that the Vega doesn't generate ringing because the telco will do this normally, but some telco's do not generate ringing and therefore the Vega unit must do this. To configure this follow the steps below
...
| Note |
|---|
NOTE Apply saves to the running memory, Save writes to the non volatile flash drive so next boot the setting will not be lost. |
Why Is There No Caller ID?
This is most likely because the caller id is coming in a separate FACILITY message (not in the SETUP message). So the Vega unit just needs to be configured to wait for this message to arrive before routing the call. To do this we just need to set a timer in the Vega unit to wait for this. Follow the steps below to configure the timer:
Log into the Web interface and go to "Expert Config -> Advanced" then you will see a section called "CLI Command" as shown below.
Enter the command "set e1t1.port.x.isdn.wait_for_calling_name_time=1000" into the text box and click Submit. The value 1000 is in milliseconds so it is 1 second; you can increase this value to see what is right for your setup.
Next a window will popup showing the command is complete enter "apply" then click Submit.
Next enter the command "save" and click Submit.
Why Is There No Caller ID on R2 (ITU) Links?
The ITU variant by spec does not request CID info from your carrier and therefore you are not getting caller id. This can also result in caller id "anonymous" being shown on the SIP leg when it gets the call. To resolve the issue simply ssh/telnet into the unit or go to Expert Config -> Advanced -> CLI Commands and enter the following commands.
...
Once this is complete then test to see if CID is working.
Why Is My CAS Link Not Providing DNIS/DID?
This can be resolved in most cases by simply changing "RX Dial Format String" and "TX Dial Format String" to from " . " to "N". This value configures the Vega to request for the DNIS and therefore the unit will get it from the telco. For more info see the admin guide at http://wiki.sangoma.com/Vega-400-Technical-documentation and look up "tx_dial_format" and "rx_dial_format" for all possible values.
Below is how to access the Dial Format String field for TX and RX and also where the "N" 's should be placed.
Why can't I set CID on outgoing calls?
This is most likely because the telco is looking at a few parameters in your SETUP message before taking the CID you are trying set. If these parameters are not set correctly then the telco will not attempt to take CID from the SETUP message.
...
| Info |
|---|
Example set ._advanced.setup_mapping.1.calling_party_number.screening="supplied" Possible Values: "not_screened", "passed", "failed", "supplied" |
Audio Quality questions
I get very poor quality audio played through my Vega
Some devices don't like Vega suppressing silence packets - even if they are just an IVR playing audio out through the Vega. Try turning VADU off for the codec(s) in use.
Why is there Double talk Issue on my Analog VEGA
In case user if user is getting double talk issue it can be resolved using below CLI command configuration:
...