Configure Etisalat SIP Trunk on Grandstream UCM

Grandstream UCM • UAE SIP Trunk Guide

Configure Etisalat SIP Trunk on Grandstream UCM

Connect an e&/Etisalat business SIP service to a Grandstream UCM by using the provider-issued trunk parameters, then build controlled inbound, outbound, DID and caller-ID rules around the real business call flow.

The important principle is simple: Grandstream provides the PBX configuration framework, while Etisalat supplies the service-specific values. Do not copy a SIP server address, password, codec, source IP or dial pattern from an online example. Use the values issued for the actual UAE circuit or account and test each direction before placing the trunk into production.

Registered or Peer TrunkDID & DOD PlanningUAE Deployment Support

Ask for Configuration SupportView Configuration Steps

Quick configuration snapshot
Trunk typeRegistered or Peer SIP
Provider hostEtisalat-issued value
NumberingPilot + DID range as supplied
RoutingInbound + outbound rules
Caller IDMatch carrier presentation rules
ValidationTest both call directions
Overview

What this configuration actually involves

A working SIP trunk is not created by entering one server address. It is the result of four pieces matching: the carrier handover, the UCM trunk object, the dial-plan rules, and the network path that carries SIP signalling and RTP audio.

Grandstream UCM systems provide the controls needed to create SIP register trunks or peer trunks, apply inbound routes, create outbound routes, associate Direct Outward Dialing numbers, and control which extensions may place calls. The exact UCM menu names can vary slightly between UCM generations and firmware, but the logical workflow remains consistent. For a register-style service, the PBX authenticates to the provider using a username, authentication ID and password. For a peer-style service, the carrier commonly identifies the PBX or customer edge by an approved IP address and SIP peer relationship. Which method applies to your Etisalat circuit must come from the service handover.

This distinction matters in the UAE because business voice services may be delivered in different ways. A managed business gateway product is not automatically the same thing as a SIP trunk that can be terminated directly on a customer-owned PBX. Etisalat’s own business support material identifies SIP Trunk as a business telephony service, while separate managed bundles may have restrictions on using an external PBX. Confirm that the ordered service is intended for PBX interconnection before changing the UCM.

The configuration should therefore start with documentation, not with trial and error. Obtain the service reference, pilot number, DID range, SIP server or peer address, authentication method, signalling transport, expected source IP, media requirements, permitted caller-ID format and supported dial format. If the provider has supplied a session border controller address, private voice VLAN, dedicated router port or static IP requirement, keep those values exactly as issued. FourTeck can review these details against the UCM design before deployment for businesses that want a controlled change rather than live troubleshooting during working hours.

Provider handover checklist

Collect these Etisalat SIP details before configuration

The safest answer to “what values do I enter?” is: enter the values assigned to your service. Public examples are useful for learning the UCM interface, but they are not credentials for a live Etisalat trunk.

01 / SERVICE

Trunk authentication method

Confirm whether the trunk is registration based or IP authenticated. This determines whether the UCM should be configured as a Register SIP Trunk or a Peer SIP Trunk.

02 / SIGNAL

SIP host and transport

Record the registrar, proxy or SBC address, the required signalling port and the transport method. Do not force UDP, TCP or TLS unless the handover requires it.

03 / NUMBERING

Pilot, DID and caller ID

Document the pilot number, full DID block and the exact format the carrier sends inbound and expects outbound. A mismatch here commonly causes routing or CLI problems.

04 / MEDIA

Codec, DTMF and RTP

Use the codec list, DTMF method and media requirements from the provider. These items affect audio negotiation, IVR key presses and media flow.

05 / NETWORK

IP, VLAN and access requirements

Confirm whether voice arrives through a dedicated router port, private VLAN, public static IP or other provider-managed path, and whether source-address restrictions apply.

06 / CAPACITY

Channels and restrictions

Know the concurrent-call entitlement, any international-dialling restrictions, emergency calling expectations and whether specific caller IDs are approved for presentation.

Step-by-step

Configure the SIP trunk in Grandstream UCM

In Grandstream’s UCM6xxx guidance, SIP trunks are created under Extension / Trunk → VoIP Trunks. The UCM6300 family follows the same trunking concept, although field names and placement may vary by firmware. Make a current backup before modifying a production PBX.

STEP 1

Confirm the UCM network path

Verify that the UCM has the correct LAN/WAN design for the voice service. If Etisalat has provided a dedicated interface, private subnet or voice VLAN, confirm that the UCM can reach the assigned SIP endpoint through that path. If the service is tied to a public static IP, make sure the carrier sees the correct source address. Avoid changing unrelated firewall, NAT or routing settings just to make registration turn green; establish the intended topology first.

STEP 2

Add the correct trunk type

Open the UCM web interface and navigate to the VoIP Trunks area. Add a SIP trunk. Choose Register SIP Trunk only when the provider has issued credentials that the PBX must use to register. Choose Peer SIP Trunk when the handover describes an IP or peer-based connection without normal SIP registration. Give the trunk a clear operational name such as Etisalat-SIP-Primary so call routes and logs remain understandable later.

STEP 3

Enter provider identity and host values

For a registration trunk, enter the provider hostname or IP, username, authentication ID and password exactly as supplied. For a peer trunk, enter the carrier peer or SBC address and any source validation parameters supported by the UCM. If the provider specifies an outbound proxy, From Domain, From User or other identity requirement, use that value rather than guessing. Spaces, prefixes and number format can matter, so preserve the handover notation.

STEP 4

Match signalling and media options

Set SIP transport, signalling port, codec preference, DTMF method and any keepalive or heartbeat options according to the service specification. A trunk may appear registered while still failing real calls if media or DTMF negotiation does not match. For this reason, do not treat a green registration state as the end of the installation.

STEP 5

Save, apply and check trunk status

Save the trunk and apply the UCM configuration. Grandstream documents a registered status for successful register trunks and reachable behaviour for peer trunks when monitoring is enabled. If the expected status is not achieved, stop before building a large dial plan. Correct the carrier reachability, credentials, source IP, transport or peer definition first.

Configuration reference

UCM trunk fields and what to verify

The table below is a planning reference, not a list of Etisalat values. Where the entry says provider supplied, use the service handover.

UCM area Typical field What to enter or confirm Common risk
VoIP Trunk Type Register SIP Trunk or Peer SIP Trunk as provisioned Choosing registration when the service is IP authenticated
VoIP Trunk Host / SIP server Provider-issued registrar, proxy or SBC Copying a public example
Authentication Username / Auth ID / Password Only if supplied for the actual service Mixing pilot number with authentication identity
Signalling Transport / port Provider-specified method and port Assuming a default when the service differs
Media Codec / DTMF Match the approved carrier profile Calls connect but audio or IVR keys fail
Numbering Pilot / DID range Exact allocated business numbers Inbound DID format does not match route
Caller ID CID / DOD Approved pilot or assigned DID format Outbound call rejected or wrong CLI shown
Routing Inbound / outbound patterns Business dial plan matched to carrier number format Overly broad rules or incorrect stripping
Network Source IP / NAT / VLAN Service-specific topology One-way audio or rejected peer traffic
Inbound calling

Create inbound routes for the pilot and DID numbers

A SIP trunk can be reachable and still deliver calls to nowhere. Inbound routes tell the UCM what to do with a number that Etisalat sends toward the PBX. Grandstream’s SIP trunk guide shows inbound rules under Extension / Trunk → Inbound Routes and uses a broad _X. pattern as a teaching example. For a production business system, it is usually better to understand the exact number format first and then create intentional patterns for the assigned numbers.

Start by making one controlled test route. Select the Etisalat trunk, enter a DID pattern that matches the number as it actually appears in the incoming SIP message, and send it to a test extension, ring group, IVR or other known destination. Call the business number from an external mobile. If the call does not hit the rule, inspect the number that the carrier is presenting. It may arrive as a full national number, a shortened DID, a pilot-plus-extension format, or another service-specific representation. Adjust the route to what is actually received rather than to what you expect.

Once the test succeeds, expand the routing plan. Reception may receive the pilot number, while direct departments or employees may use individual DIDs. Time conditions can send after-hours calls to voicemail or another destination. Keep the rule set readable. Names such as Etisalat-DID-Sales and Etisalat-Pilot-Reception make later troubleshooting easier than generic labels such as Route1.

Answer first: If inbound calls reach the UCM but not the destination, verify the DID format and inbound rule before changing trunk authentication. The trunk may already be working correctly.
Outbound calling

Build a controlled outbound route

Grandstream places outbound routing under Extension / Trunk → Outbound Routes. An outbound route decides which dialed numbers may leave the PBX, which SIP trunk should carry them, what digits should be stripped or prepended, and which users have permission to use that path.

Do not begin with one unrestricted catch-all route for every extension. First confirm the number format that Etisalat expects. The carrier may require a national format, international format, prefix treatment or specific presentation rule. Build the UCM pattern around the confirmed service. Then decide whether users will dial numbers naturally or use an access prefix. If an access digit is used, the UCM can remove it before sending the call to the carrier. If users dial natural numbers, the route can match those directly.

Grandstream also provides privilege levels and source caller filtering so an administrator can control which extensions may use a route. This is useful when international calling, premium destinations, call-forwarding paths or department-specific trunks must be restricted. The permission level is a control hierarchy, not a guarantee that the carrier itself supports a given destination. The SIP service must also allow that call type.

Test one external destination in each permitted category: local fixed line, mobile and international if enabled. Confirm that the called party receives the call, the correct business caller ID appears, audio works in both directions, and the call clears normally. A successful outbound call proves more than trunk registration because it validates authentication or peer trust, route matching, number formatting, caller ID and media together.

Caller ID & DOD

Map outbound identities to the numbers Etisalat assigned

Direct Outward Dialing allows selected extensions to present an approved external number when they call out. Grandstream’s UCM guidance lets administrators associate DOD entries with extensions and also provides caller-ID controls at multiple levels. The practical goal is to make the identity sent by the PBX agree with what the carrier permits.

For example, reception may need to present the main company number while sales staff present direct DIDs. That only works when those numbers belong to the service and Etisalat allows them as outbound presentation identities. Do not configure arbitrary numbers just because the UCM accepts the field. Carriers can reject or normalize caller ID that is not authorised on the trunk.

If outbound calls connect but the wrong caller ID appears, inspect the UCM DOD and trunk CID hierarchy before changing the dial pattern. Grandstream documents that caller ID can be influenced by the trunk, trunk DOD, outbound route, extension and global settings. A value at one level may override another. Keep the design simple and document which layer owns external presentation.

Pilot presentation

Use when the business wants one main callback identity and the carrier allows the pilot as CLI.

Direct DID presentation

Associate approved DIDs with the appropriate extensions or groups where direct callback is required.

Header consistency

If Etisalat specifies From, P-Asserted-Identity or another identity treatment, align the UCM configuration with that requirement.

Feature deep dive 1

Grandstream UCM trunk status is only the first test

A registered trunk confirms that the PBX can complete the registration exchange, but it does not prove that every call scenario will work. A peer trunk may show reachability when heartbeat detection is used, yet caller ID, DID routing, number translation or RTP media can still be wrong.

Treat the UCM dashboard as a health indicator, not a final acceptance test. A proper handover includes real calls, multiple destinations, inbound DIDs, DTMF to an IVR, transfer, hold, call clearing, concurrency and failure behaviour.

Acceptance evidence

  • Expected trunk state on UCM
  • Outbound calls complete with correct CLI
  • Inbound pilot and DID calls reach correct destinations
  • Audio works in both directions
  • DTMF works through IVR or auto-attendant
  • Concurrent-call test matches the ordered service
Feature deep dive 2

Network and NAT planning for SIP media

SIP signalling establishes the call; RTP normally carries the voice media. When a call rings and connects but one side cannot hear the other, the problem is often in the media path rather than the DID or outbound dial pattern.

The correct network design depends on how the Etisalat service is delivered. A private carrier handoff may not behave like an internet SIP provider. A public peer may depend on a fixed source IP. A routed voice VLAN may require a specific gateway. Follow the carrier topology and then configure the UCM NAT options to match the real placement of the PBX.

Avoid exposing the UCM directly to the public internet merely to make a trunk work. Use the intended firewall and access-control design, restrict management access, and permit only required signalling and media paths. When troubleshooting, change one network variable at a time so the final working state is understood and documented.

Feature deep dive 3

Dial-plan control protects usability and call policy

A good dial plan makes calling natural for users while ensuring the PBX sends a carrier-approved number format. It also limits which extensions can use expensive or sensitive routes. Grandstream provides route patterns, digit stripping and prepending, source caller filters, extension permissions and time conditions that can be combined to create this control.

Confirm

What users should dial for local, mobile and international calls.

Translate

Strip or prepend only when the carrier requires a different number format.

Restrict

Use permissions or source filters for international or special call paths.

Document

Name routes clearly and record why each pattern exists.

Answer first: if a user gets “all circuits busy” or a rejected call while other destinations work, inspect the matching outbound rule, number translation and carrier permissions for that destination before rebuilding the trunk.

Buyer and deployment decision guide

What to check before changing a live Etisalat trunk

The biggest deployment risk is treating the SIP trunk as a generic internet account. The UCM must match the actual Etisalat provisioning, number plan and network handoff. Review the following points before the maintenance window.

01 / FIT

Correct service type

Confirm that the service is intended for customer PBX interconnection and whether the UCM should register or operate as an authenticated peer.

02 / MATCH

Compatibility and firmware

Record the exact UCM model and firmware. Menu names and available SIP options can differ, so the implementation should be mapped to the installed release.

03 / FLOW

Number and call-flow design

Decide where the pilot and each DID should ring, which users need external CLI, and which call categories each extension may place.

04 / RECOVERY

Rollback and support path

Keep a UCM backup, provider contact reference and previous routing information so the system can be restored if the maintenance window does not complete successfully.

Troubleshooting workbench

Common Etisalat SIP trunk problems on Grandstream UCM

Troubleshoot from the symptom backward. Do not change authentication, NAT, dial patterns and codecs at the same time. A structured test usually reveals whether the failure is registration, signalling, routing, identity or media related.

Trunk will not register

Confirm that this is actually a registration-based service. Then verify provider host reachability, username, authentication ID, password, transport and source IP. Check whether the handover requires an outbound proxy or specific From identity. If the service is IP authenticated, repeated credential changes will not solve the problem because the wrong trunk type has been selected.

Peer trunk is not reachable

Verify routing between the UCM and the carrier peer, the expected source and destination addresses, firewall policy and whether heartbeat or SIP OPTIONS monitoring is appropriate for that service. Some carrier peers may not respond exactly like a UCM-to-UCM peer, so reachability monitoring should be interpreted together with real call tests and provider guidance.

Outbound call gets 403, 404 or immediate rejection

Check the number format sent by the UCM, caller ID or DOD, authentication identity, From domain and whether the destination is permitted on the service. A 4xx response is signalling feedback; use the SIP message and provider response to determine what field is being rejected rather than trying random codecs.

Inbound call reaches the trunk but not the extension

Inspect the DID that the UCM receives and compare it with the inbound route pattern. Confirm the selected trunk and default destination. If a broad test pattern works but the exact DID route does not, the issue is likely number matching rather than provider registration.

One-way audio or no audio after answer

Focus on RTP media routing, NAT awareness, firewall policy and the IP addresses advertised in SIP/SDP. Confirm that the provider’s media path is permitted in both directions. If signalling is successful and only audio fails, avoid rewriting the DID route because it is probably not the fault domain.

IVR answers but keypad input does not work

Compare the UCM DTMF setting with the provider requirement and the endpoint behaviour. The call path must agree on how digits are transported. Test with more than one external caller if possible so a handset-specific issue is not mistaken for a trunk problem.

Wrong or anonymous caller ID

Review the assigned pilot/DID numbers, trunk caller ID, DOD mapping, extension caller ID and outbound route CID. Confirm the format the carrier expects. If Etisalat normalises the identity, compare what the UCM sends with what the remote party ultimately sees before deciding which side needs adjustment.

Calls work until concurrent usage increases

Check the ordered simultaneous-call capacity, UCM resource usage, WAN quality and whether the carrier limits channels. A test with one call cannot validate a multi-channel business service. Perform controlled concurrency testing during commissioning without disrupting normal operations.

Validation plan

Test the trunk like a business service, not a lab extension

A complete test should represent the calls employees and customers actually make. Record the result of each scenario so failures can be reproduced and discussed with either the PBX administrator or the carrier.

Inbound pilot

Call the main number from an external mobile and confirm the intended IVR, receptionist or ring group.

Inbound DID

Test at least two direct numbers and confirm each reaches the correct destination.

Outbound categories

Test fixed, mobile and international destinations only where the service is authorised for them.

Caller ID

Confirm the remote party receives the approved pilot or DID presentation expected for that extension.

Feature interaction

Test hold, attended transfer, blind transfer, IVR DTMF and voicemail paths used in normal operation.

Concurrent calls

Validate the expected number of simultaneous calls within the ordered capacity and maintenance window.

Compatibility note

Do not confuse Etisalat managed voice bundles with a direct SIP trunk

This point is important when a UAE office already has an Etisalat business gateway. Etisalat’s published Business in a Box technical FAQ states that PBX platforms do not function with that managed service. The same support material separately references SIP Trunk among business telephone services. That means the presence of SIP phones or voice capability in a managed bundle does not automatically mean a customer-owned Grandstream UCM can register to it as a trunk.

Answer first: before purchasing hardware or scheduling a migration, confirm that the ordered Etisalat service is specifically provisioned for external PBX interconnection. Ask the account manager or service team for the SIP trunk handover document. If the service is a managed PBX replacement or gateway product, the integration method may be different or unsupported.

This check can prevent hours of troubleshooting a system that was never meant to expose SIP trunk credentials to the customer’s UCM. When FourTeck reviews a project, the service type, circuit handoff, PBX model, DID range and desired call flow should be confirmed before configuration work begins.

Deployment guidance

Information to send FourTeck for a useful configuration review

The fastest way to diagnose or plan a Grandstream UCM SIP trunk is to provide the technical context in one package. Mask passwords when sharing screenshots unless a secure support method has been agreed.

  • Exact Grandstream UCM model and current firmware version
  • Whether the system is already in production
  • Etisalat/e& service type and handover document
  • Trunk authentication type: register or peer/IP based
  • SIP registrar, proxy or SBC values supplied by the provider
  • Pilot number and DID range
  • Expected inbound destinations for each number or number group
  • Required outbound caller ID behaviour
  • Number of users and simultaneous calls
  • Network diagram showing UCM, firewall/router and carrier handoff
  • Examples of failed numbers, time of test and SIP response if available
  • Whether DTMF, recording, call queues, IVR, remote extensions or failover are part of the requirement

With these details, configuration support can focus on the actual fault domain rather than starting from generic defaults.

UAE service support

Grandstream UCM and SIP trunk assistance in the UAE

FourTeck supports business telephony enquiries across the UAE with Grandstream UCM selection, configuration review, SIP trunk planning, inbound and outbound route design, DID mapping, IP phone deployment and troubleshooting. Support scope depends on the installed PBX, available administrative access, carrier handover information and the condition of the existing network.

For a new deployment, the team can help review the required UCM capacity, endpoint count, call-flow design and compatibility with the selected service before implementation. For an existing system, a troubleshooting engagement can focus on trunk status, call routing, SIP signalling, caller ID, DTMF, one-way audio or migration from older voice services. Carrier-side provisioning remains under the telecom provider’s control, so issues involving account activation, assigned numbers or carrier routing may require coordination with Etisalat/e&.

Contact FourTeck Sales

UAE coverage

Dubai, Abu Dhabi, Sharjah and Ajman project support

Businesses in Dubai, Abu Dhabi, Sharjah, Ajman and other UAE locations can contact FourTeck for Grandstream UCM and business voice project assistance. The useful starting point is the same in every emirate: identify the UCM model, carrier service, number range, user count, call-flow requirement and network handoff. From there, FourTeck can help determine whether the requirement is a simple trunk setup, a call-routing redesign, an IP PBX upgrade, a phone deployment or a wider network and voice migration.

For multi-site organisations, document whether each branch has its own carrier service or whether external calling is centralized through one PBX. This affects routing, resilience, numbering and WAN dependency. Availability of on-site work, remote support and hardware is project dependent; request the required location, preferred date and scope when asking for assistance.

Regional project enquiries

GCC and Africa communication projects

FourTeck also receives business technology enquiries connected with selected GCC and Africa markets. SIP carrier parameters, telecom regulations, number formats, warranty handling and delivery methods vary by country, so a UAE Etisalat configuration should not be copied into another market. Projects involving Saudi Arabia, Qatar, Oman, Kuwait, Bahrain, Kenya, Uganda or wider Africa requirements should be reviewed against the local carrier and the actual PBX deployment.

Regional platforms can be used for the appropriate enquiry channel, while the technical method remains evidence based: confirm service handover, PBX compatibility, network path, numbering, call policy and support scope before configuration.

Related FourTeck resources

Useful Grandstream UCM and business voice options

If the current PBX needs an upgrade or the trunk project is part of a wider communication refresh, these FourTeck resources can help with model selection and related deployment planning.

Grandstream brand range

Browse Grandstream IP PBX, phones, gateways and networking products for business communication projects.

Explore Grandstream products →

Grandstream UCM6301

A compact UCM option for smaller deployments that still require SIP trunking and business call control.

Review UCM6301 →

Grandstream UCM6302A

Consider this audio-series option when the project requires a dedicated on-premise IP PBX with SIP trunk support.

Review UCM6302A →

Grandstream Wave solutions

Extend a compatible UCM deployment to desktop and mobile users where remote communication is part of the requirement.

Explore Grandstream Wave →

Configuration assistance

Send the UCM model, provider handover and call-flow requirement for a practical review.

Contact FourTeck →

Why FourTeck

Support focused on the real call path

SIP trunk problems can cross several administrative boundaries: the carrier service, edge router or firewall, IP PBX, dial plan, endpoints and business call flow. A useful support process identifies which layer is failing before making configuration changes. FourTeck approaches UCM projects with that operational view.

Requirement review

Translate provider details and business call flow into a configuration plan.

UCM guidance

Review trunk type, routes, DOD, permissions and relevant system settings.

Network checks

Assess the connectivity path when signalling or audio symptoms point outside the dial plan.

Testing and handover

Validate real inbound and outbound scenarios and document the working design.

Frequently asked questions

Etisalat SIP trunk and Grandstream UCM FAQ

01

Can I use the same Etisalat SIP settings shown in an online example?

No. Example credentials and server addresses are for demonstration only. Use the SIP server or peer, authentication method, username, password, transport, number format and media profile issued for your own Etisalat/e& service. If those values are missing, request the trunk handover information before configuring the UCM.

02

Should I create a Register SIP Trunk or a Peer SIP Trunk?

Choose the type that matches the carrier provisioning. A register trunk normally uses credentials so the UCM registers to a provider. A peer trunk normally relies on an IP-based SIP relationship. The Etisalat service handover should identify which model applies. Do not switch types simply because one status looks easier to achieve.

03

Where do I create the SIP trunk on a Grandstream UCM?

Grandstream’s UCM guidance uses the web interface path Extension / Trunk → VoIP Trunks. The exact wording can vary by UCM family and firmware. After creating the trunk, inbound and outbound routes are configured in their respective routing sections and then tested with real calls.

04

Why does the trunk show registered but calls still fail?

Registration only confirms one part of the SIP relationship. Calls can still fail because of outbound route patterns, number formatting, caller ID, DID matching, carrier permissions, codec negotiation, DTMF or RTP media routing. Test signalling and call flow separately rather than assuming a green registration state proves the full service.

05

How should I route Etisalat DIDs to UCM extensions?

Create inbound rules that match the DID format the UCM actually receives from the carrier, then send each number or number group to the required extension, ring group, queue or IVR. Start with a controlled test destination, confirm the received digits, and only then build the full DID routing plan.

06

How do I set the outbound caller ID?

Use only numbers assigned to the business service and follow the carrier’s permitted presentation format. Grandstream supports trunk caller ID, DOD, route caller ID and extension-level settings. Keep the design simple so it is clear which layer owns the external identity, and test what the remote party actually receives.

07

What causes one-way audio on a SIP trunk?

One-way audio usually points to the RTP media path rather than to the inbound DID rule. Review firewall and NAT behaviour, source and destination addressing, the IP information advertised during call setup, and the carrier’s required media path. Keep the provider topology in mind, especially when a dedicated voice circuit or VLAN is used.

08

Can I connect a UCM to Etisalat Business in a Box?

Do not assume so. Etisalat’s published technical FAQ for Business in a Box states that PBX platforms will not function with that service. A separately provisioned SIP Trunk is a different business voice service. Confirm the exact product ordered and whether it is intended for customer PBX interconnection.

09

Can FourTeck help troubleshoot an existing UCM trunk?

Yes, subject to project scope and access. Send the exact UCM model, firmware, trunk type, provider handover, DID range, network diagram and examples of failed calls. This information helps separate carrier provisioning, PBX routing and network problems before configuration changes are made.

10

What should I test before declaring the SIP trunk ready?

Test inbound pilot calls, multiple DIDs, outbound destinations, caller ID, two-way audio, IVR DTMF, hold, transfers, call clearing and the expected number of simultaneous calls. If failover or after-hours routing is part of the design, test those paths as well and record the results for handover.

Configuration assistance

Need help with your Etisalat SIP trunk and Grandstream UCM?

Send the UCM model, firmware, Etisalat service handover, DID range, network layout and required call flow. FourTeck can help review the trunk type, routing, caller ID, network path and test plan for a controlled UAE deployment.

For the most useful response, include one failed call example with the number dialed, time of test and the result shown on the UCM.

Request Configuration Support

Need UCM help?Contact FourTeck

Scroll to Top