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.

Command

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: 

Command

On the front panel, during calls the ISDN LED will be seen to be on solidly, and between calls the LED will flash. 

For further information about configuring BRI systems, see Information Note ‘IN_26 BRI connection checklist’

Command

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: 

Command

To enable tunnelling of the Low_Layer_Compatibility IE (mie_id=7c) 

Command

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.

Unauthorised:  This SIP message requests the Vega to re-submit its registration request, but this time containing 'Authentication information' based on the 'nonce' value returned in the Unauthorised message.  This is a normal part of Authenticated registration.  If the second registration fails, suspect wrongly configured authentication username / password details in either the Vega or the Registrar.

Decline:  This message indicates that the Registrar does not want to / does not know how to support registration of this device.  Typically this means that either the endpoint ID, or registration domain is not known by the registrar.

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.

By default, when a call is being made to (or through) a Vega FXS port, that Vega will generate ringback tone and send it over VoIP.  To inform the initiating device that there is media to play the Vega sends a 183 'Session Progress' SIP message with an appropriate sdp.  Some proxies / calling devices, however, do not support '183 Session Progress' and require a '180 Ringing' to be used in order that ringback tone is played to the caller.  

You can change the Vega to send a '180 Ringing' (to tell the local device to generate its own ringback) and not send media, rather than the '183 Session Progress' together with a media stream, by setting tones.net.ring from 1 to 0

For further information, see 'FXS SIP parameters for ringback generation to the VoIP interface' in the Vega primer.

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.

Vega gateways, being real time devices cannot afford to wait for the end tone indicator before playing out the tone for the duration indicated in the packet, because otherwise the tone played out may overlap the words the caller makes after pressing the tone.  The Vega starts playing the tone when it receives a start RFC2833 message and stops when it receives an end message.

Some devices have been seen that send start, continuation and then multiple end RFC2833 messages in a very rapid burst (around 4 milli-seconds).  Although the RFC2833 message may report a tone duration of for instance 500ms, the Vega will only play the tone for the 4 milli-seconds the gap between the first tone on message and the first end message (too short to be heard).

To handle this the Vega supports a 'one shot' mode.  In this case the Vega will play a fixed length tone however long the gap between the first tone on message and the first tone end message.  (The duration is defined by the configuration parameter dtmf_cadence_on_time.)  To enable one shot mode:

Command

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". 

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.

If this is the case in show support you will find below o/p:

1. This can simply be resolved by setting up the correct From Header field under --> Expert Config --> SIP--> SIP profiles:

2. As shown in above picture click on Modify button, a new window will open, in this window please change the “From Header userinfo” field to “Calling Party“ from drop down button:

   1. Click Apply and Save changes.

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:

Put Command

… these commands write a text file of the Vega configuration onto the (T)FTP server

Get Command

… 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?

Answer:

Inbound Calls (FXO->SIP) 

You can edit the dial plan to allow each port to have its own "DID". To do this simply go to step "Expert Config->Dial Plan->To_SIP" and remove all other dial plan entries. Then below is an example to add a DID to 8 FXO ports. 

Now in this example we assigned a DID to each line. You can group lines by using the example below.

Example #2 - Source: IF:020[135] Destination: IF:9901,TEL:9054741990
Explanation - This assigns "9054741990" to ports 1, 3 and 5. Note ports 2 and 4 are NOT included. 

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.  

Outbound Calls (SIP->FXO)

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>

If you want to group lines together as done with the inbound calls you can create "Call Presentation Groups". To do this go to "Expert Config -> Dial Plan-> Call Presentation Groups". Below is a screen shot of presentation group "0600" which contains interfaces "0201" and "0202" which are FXO #1 and FXO #2. 

So to group the first two ports together you can use the presentation group and the dial plan rules below. You will notice there is only 7 rules now and the first rule points to the new presentation group. Also as noted in the first example the caller ID has to be sent from SIP in the from user part. This is how the correct port is chosen when making a outbound call. 

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:

Enable Fax Buffering

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/8^th 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.  

FXO, BRI, T1, E1

When using the Trix Box with an FXO, BRI, T1 or E1 Vega gateway the Vega is typically being used as a trunking gateway; it therefore needs to be configured as trunks on the ‘Trix Box’.  Once configured ‘Trix box’ will send calls to the Vega and outbound calls will work fine.

‘Trix Box’ does not accept calls from the Vega unless the Vega registers with ‘Trix Box’.  Set up a single registration user on the Vega, and make sure that the registration username is the same as the ‘Outgoing Settings TRUNK NAME’ set up on the ‘Trix box’.

Also ensure that the correct ‘Peer details’ are set up.  The values tested at VegaStream are shown in the screenshot below.

Also make sure the Vega is configured for authentication; the ‘secret’ in the Peer details is the password that needs to be configured in the Vega authentication.  The authentication username is the same as the registration username, and is the 'Outgoing settings Trunk Name'.

The trunk name, registration username and authentication username shown in the example below is ‘trix’

Check that the Vega registers (‘sip show reg’ or ‘show registrations’).  

FXS

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:

Install Brekeke ONDO onto your PC

On the PC go into the firewall and allow 5060 access (control pannel > Security Centre > windows firewall, select the 'Exceptions' tab then 'Add Port' and add an entry name=SIP, Port=5060, Protocol=udp)

Run up Ondo and log in to its web browser interface (default username=sa, default password=sa)

Select the Config tab
> set 'Server Name' = IP address of the Brekeke PC
> set 'Server Location' = IP address of the Brekeke PC
> select Save changes

On the config tab select 'SIP (General)'
> set 'NAT traversal ' = off
> set 'Register Authentication' = off
> set 'Invite Authentication' = off
> select Save changes

On the config tab select 'SIP (Advanced)'
> set 'Upper Registration' = off
> set 'Thru Registration' = off
> select Save changes

To activate the Brekeke select the 'Start Shutdown' tab.
> select 'Shutdown' if the Brekeke is Active
> select Start

After rebooting the PC always do a 'Shutdown' followed by a 'Start' to ensure that the Brekeke has started up correctly

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: 

Dialplan

To provide the Prefixes in Cisco Call Manager format, also add dial plans with source expressions: 

Dialplan

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.

Required Cisco configuration - including the overriding of bearer capability is documented in the Cisco AS5300 and Vega configuration guide available on the www.VegaAssist web site. 

cleardown 47 
If a call made from a Vega gateway to a Cisco gateway via a Cisco call manager results in a cleardown 47, it may be that the Vega needs to be configured to operate in h245 tunnel mode. Try:

Command

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.

When working with LCS, turn off Q.850 headers by:

Command

Note 2. LCS has been seen to behave strangely, sending a TCP ACK in a TCP reset IP packet, but then requiring the SIP message that it had just ACKed to be re-sent.  (Specifically seen when LCS closes the TCP session after a SIP ACK).  This can be fixed by ticking the check box 'Throttle As Server' on LCS.
(This problem was observed in LCS version SP1 2005 version 2.0.547.0 running on windows 2003 service pack 1).

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 ...."

The QuesCom gateway does not handle 183 Progress messages and if it receives one it will never play out any RTP audio sent from the Vega to it for that call (even RTP received after answer).

To pass media through before answer, the QuesCom does support 180 Ringing with SDP.

To configure the Vega to use 180 Ringing messages rather than 183 Progress messages, look at the primer section "Selecting Generation of Progress Tones vs Media Pass Through", and especially look at the table for the relevant product that shows the Vega parameters that affect the 180 / 183 messages.

[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:

• VADU is set to 'no'

• EC Enable is set to 'disabled'

• Resampling control is set to 'disabled'

• for G711ulaw codec set VP FIFO Nominal Delay = '80'

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:

Command

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:

Command

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:

Command

Make the test call

Debug

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

1. Log into the Web interface and go to "Expert Config -> Advanced" then you will see a section called "CLI Command" as shown below. 

2. Enter the command "set _advanced.isdn.user_progress=1" into the text box and click Submit. 

3. Next a window will popup showing the command is complete enter "apply" then click Submit. 

4. Next enter the command "save" and click Submit. 

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: 

1. Log into the Web interface and go to "Expert Config -> Advanced" then you will see a section called "CLI Command" as shown below. 

   1. 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. 

   2. Next a window will popup showing the command is complete enter "apply" then click Submit. 

   3. 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. 

Command

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 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. 

So below is all the values that define the calling party number which is the CID you are trying to set. Now the first two "Number Plan" and "Number Type" are the main ones to try setting. The other two could be required as well but normally are not. Also each parameter has an example of the command to set it with the default value of "supplied". Simply change "supplied" to any of the possible values and this will set the value. Then run "apply" to apply the value before making a call. Once you find the values that work run the command "save". Also normally setting "unknown" or "national" for both number plan and number type resolve the issue.

To run these commands ether telnet/ssh into the system or go to "Expert Config -> Advanced -> CLI Command" in the UI. 

Calling Party Number Plan

Description: Override the Numbering Plan Identification field value for setup messages (ISDN or H.323); supplied = do not override the NPI value (pass it through from the incoming call)

Possible Values: "Unknown", "isdn_telephony", "data", "telex", "national", "private", "supplied"

Calling Party Number Type

Description: Override the Type Of Number field value for setup messages (ISDN or H.323); supplied = do not override the TON value (pass it through from the incoming call)

Possible Values: "Unknown", "international", "national", "network_specific", "subscriber", "abbreviated", "supplied"

Calling Party Number Presentation

Description: Override the Presentation Indicator field value for setup messages (ISDN or H.323); supplied = do not override the PI value (pass it through from the incoming call) 

Calling Party Number Screening

Description: Override the Screening Indicator field value for setup messages (ISDN or H.323); supplied = do not override the SI value (pass it through from the incoming call) 

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:

Command