The SIP address that you signal to is an address on an SBC (Session Border Controller) that is designed to route calls and protect our network. Unfortunately, ICMP (ping) traffic is not supported. If you need a test point to help determine the cause of packet loss or jitter, please use echo.clearfly.net.

To make a long story short, dial tone generation in a SIP or PRI environment is the responsibility of the customer's PBX. Dial tone will never be provided over these services by your phone company. For a more detailed explanation, read on . . .

The easiest way to answer this question is to explain how traditional analog POTS service works versus newer digital technologies. On a traditional analog phone line from your local phone company, when you pick up the phone (go off-hook), the line running from your phone connects directly to the phone company's switch, which generates dial tone and then listens for DTMF tones as you dial each digit. In contrast, with SIP or PRI there are not dedicated lines running back to a switch for each channel. Instead, there is a trunk which has a certain number of channels available to it. When you pick up a phone, your PBX or phone generates dial tone and then collects the digits as you dial them. When the PBX (or phone) determines that you have dialed a complete number, it sends a digital message to the phone company's switch with the calling number, the number to be called and any relevant channel (for PRI) or RTP port (for SIP) information. A channel for the call is then dynamically allocated and your call completes as expected. Note that the calling number is part of the message signaled to the phone company, which is why digital services like SIP and PRI allow you to specify the calling number that will show up in the called party's caller-ID.

When a carrier hands off a PRI or RBS T1 trunk, it is common for inbound calls to work through channels in an ascending order and for outbound calls to working through channels in a descending order. However, the concept of channels does not apply to SIP trunks. Unlike a PRI, in which there are 23 fixed voice channels, the number of channels possible over a SIP trunk is limited only by available bandwidth, so instead of choosing a "channel", SIP endpoints exchange SDP messages during call setup. Through these messages, SIP endpoints dynamically negotiate the following parameters for each call:

• Codec
• Packet size (ptime, in milliseconds)
• Media IP (unidirectional -- each side specifies its own IP)
• Transport Port (unidirectional -- each side specifies its own port)

How these parameters appear on a user's phone system is entirely up to the programming and defaults built into the system itself. The phone company has no control over how these appear on a user's system, so any changes in call appearance order will have to be requested with the phone system vendor. There is also a chance Clearfly may have relevant configuration details on a "Common Issues" page for your phone system. Interoperability information can be found here.

Every Clearfly trunk supports 7- or 10-digit local dialing. If we receive a 7-digit number then we'll append the area code assigned to the trunk before routing the call. The area code assigned to a trunk is visible as the "Default NPA" in the real-time switch information view in the Clearfly Portal.

To make an international call from a Clearfly trunk simply prepend 011 + the country code to the number or send the number in E.164 format.

Examples

• 011 Prepend - To call 40 - 42 89 90 in Germany (country code 49), simply dial 011-49-40-428990
• E.164 - To call 40 - 42 89 90 in Germany (country code 49), simply send +4940428990

First of all, support for registered trunks varies by phone system make, model and even software version. Please check our interop page to see what Clearfly Communications recommends for your phone system.

For a detailed discussion of the differences between static & registered SIP trunks see KB112.

Although Clearfly has systems in place that can gather a substantial amount of data when we are helping to troubleshoot call issues, there are many problem scenarios in which it is difficult or impossible for our support technicians to gather the information necessary to isolate an error from within our network or systems.

For example, if a customer's phone system is behind firewall and there are indications that packets are being dropped somewhere along the path, a packet capture outside of the firewall can tell you if the packets are even reaching your network and a packet capture inside of your firewall can tell you if the packets are making it through the firewall or being blocked by a security policy.

Alternatively, if a customer is having voice quality problems a coordinated packet capture in which Clearfly support technicians and your phone technicians work together to analyze packet loss and jitter on both sides of a last-mile Internet connection could provide a critical piece of documentation to submit to an uncooperative ISP.

The versatility of packet captures and the in-depth insights they can provide into a problem make them one of our favorite troubleshooting tools. You can read more about the hows and whys of packet captures here.

It is often important that users be allowed to specify their calling number, especially for cases in which a user has call forwards in place and wants to preserve the original calling number. To accommodate this, Clearfly will look at the FROM header of an INVITE message for the user's preferred calling number. If the user-part of the FROM URI is a valid NANP number, that number will be used as the calling number when the call leaves Clearfly's switch. If the number isn't valid NANP, Clearfly will use the customer's DN (visibile in the Clearfly Portal) as the calling number.

For customers using the m.cfly.co realm, Clearfly has to be able to associate your call with the SIP trunk configured in our switch. In order to do this, if the number in the FROM header (the calling number) is different from the number (DN) you used to register your trunk, Clearfly requires that the DN be specified in the P-Asserted-Identity (PAI) header of your SIP messages. If you're not sure how do to this, please check our interop page to see if Clearfly has a configuration recommendation for your phone system.

For example, if your DN is 4065551000, but you want your calling number to read 4065550009, your FROM and PAI headers would look something like:

From: <sip:4065550009@m.cfly.co:5060;transport=UDP>

P-Asserted-Identity: <sip:4065551000@m.cfly.co> or P-Asserted-Identity: <sip:4065551000>

Failure to set this header will result in the call being rejected with a "403 Forbidden" message.

Iridium numbers are popular international toll fraud targets from compromised phone systems, and with some calling rates exceeding $5/min vast long distance bills can accumulate very quickly. In order to mitigate this potential liability, Clearfly now blocks direct calls to Iridium prefixes. Calling an Iridium phone is still possible, however, via a mechanism known as two-stage dialing. In order to place a two-stage call to an Iridium number, you can simply place a call to Iridium's Arizona gateway at (480) 768-2500. Once connected you will be prompted to enter the 12-digit Iridium phone number, at which point your call will be routed to the target Iridium handset.

Although Clearfly recommends that users allow all traffic from Clearfly's voice network, this is not possible for some customers. For those that require static trunks or restrictive NAT translations (and bearing in mind that this information may change in the future), Clearfly's SIP signaling traffic will always originate from UDP port 5060 and RTP media traffic will originate from UDP ports 10,000-59,999. If you are adding translations through your firewall, the specific UDP ports you translate for media and signaling will be determined by your PBX configuration, not Clearfly's ports. If you have a static trunk and would like your SIP signaling traffic to originate from a port other than 5060, Clearfly allows this to be changed on the fly via the Clearfly Portal.

Clearfly marks (tags) signaling (SIP) and media (RTP) traffic as DSCP EF (expedited forwarding). Even if your ISP supports QoS and can prioritize download traffic, there are a couple of things to bear in mind: 1) in order to prioritize upload traffic, you need to ensure that it is marked as DSCP EF in your phone system or router/firewall and prioritized as it leaves your network, and 2) once the voice traffic leaves your ISP's network, there is no guarantee that intermediate carriers between Clearfly and your ISP will properly prioritize the traffic.

DSCP is enumerated in the first 6 bits of the DiffServ (ToS) byte in an IP packet, and DSCP EF may be represented differently in various systems. The following values are all equivalent:

DiffServ

• Decimal: 184
• Hex: 0xb8
• Binary: 10111000

DSCP

• Decimal: 46
• Hex: 0x2e
• Binary 101110

Often after moving to an VoIP-based phone system a customer will report that they are receiving random calls which only ring once or twice and if answered have nobody on the other line. These calls often show as being from a 3 or 4 digit number such as 100 or 1001. They can be very frustrating as the source of the calls is a mystery and there does not appear to be any way stop the calls from coming in. Thus the customer calls Clearfly to request that they calls be blocked.

In reality these calls are not even coming in through Clearfly. These calls are indicative of a phone system which is responding to call setup messages from anywhere on the internet. These calls, while seeming trivial and annoying, usually have a purpose in that they have unknowingly identified the customer phone system as a potential target for international fraud.

Steps should be taken immediately to ensure that the phone system only responds to SIP messages from configured hosts. This can be done by verifying security settings with the phone system manufacturer.

SIP messages from Clearfly will only originate from the IP address which your system is configured to communicate with.

When all subscribed concurrent call sessions (CCS) are in use on a SIP trunk or a PRI, no further inbound or outbound calls will be allowed.

Inbound calls will result in a SIP 486 Busy Here message directly from Clearfly's switch and the caller will hear a busy signal. No signaling will be sent to the customer's phone system.

Outbound calls from the customer's phone system will result in a SIP 503 Service Unavailable message. For PRI handoff, the SIP 503 message will be mapped to ISDN cause code 41 (Temporary Failure) message. For either SIP or PRI a reorder tone (fast busy) is typical, but each phone system will handle the received message differently and the resulting behavior will be determined by the type of phone system and how it is programmed.

Clearfly supports the following N11 numbers:

• 211 - Local community resource referral service
• 311 - Non-emergency municipal services
• 411 - Directory assistance (each call results in a charge on your bill)
• 511 - Road conditions
• 611 - Clearfly customer service
• 711 - TDD/TTY relay (TRS)
• 811 - Underground public utility location (Call Before you Dig)
• 911 - Emergency services

For other interesting numbers Clearfly supports, click here.

By default G.711u and G.729 are supported on all Clearfly SIP trunks and subscribers. There are a few things you should keep in mind, though:

• SIP codecs are negotiated on a call-by-call basis, so the actual codec used for a particular will vary based upon the end-to-end configuration and capabilities of SIP endpoints involved in that call.
• Even if G.729 is the preferred codec, G.711u must be supported as a fallback option for all calls:
  • G.729 is best-effort; not all endpoints support G.729.
  • Clearfly does not currently transcode between codecs, so if you configure your system to support only G.729 and the other side does not support G.729 the call will not complete.

• For both static and registered SIP trunks: Clearfly requires that the connection (c=) IP address and port in the SDP be the public IP address and port that media is originating from on your phone system.
• For static SIP trunks: Clearfly requires that the host part and port of the Contact URI be the public IP address and port that Clearfly's switch can send SIP traffic to.

Clearfly supports RFC 2833 or RFC 4733 for DTMF relay with a default RTP payload type of 101.

In order to simplify configuration for the vast majority of our registered SIP trunking customers, Clearfly's SBC automatically associates signaling to a customer based upon the source IP address of their SIP signaling. This can cause some signaling from customers with mutliple registered trunks on the same system to be associated with the wrong trunk, which can cause authentication failures when new INVITE messages are received.

Affected customers have two options, both configurable via the Clearfly Portal:

1. Change their realm from sc.cfly.co to a dynamic realm. When customers register to a dynamic realm, Clearfly will be able to automatically insert P-Asserted-Identity headers into relevant packets, minimizing the work required and potential for misconfiguration.
2. Change their realm from sc.cfly.co to m.cfly.co. Customers registered to m.cfly.co are required to insert a P-Asserted-Identity header containing their username to ensure that calls can be matched to the correct SIP trunk. See this FAQ for more details.

Clearfly supports encrypted signaling (SIP-TLS) and media (SRTP) for our SIP trunks and subscribers. In fact, if you establish a TLS trunk with Clearfly, we require that your system support encrypted media as a safeguard to ensure that phone calls you expect to be secure are actually secure. This safeguard can cause problems for some systems that register with SIP-TLS but don't actually support SRTP; for these systems inbound and outbound calls will fail when they try to negotiate an unencrypted media session.

Possible solutions are to:

1. Enable SRTP on your phone system, or
2. Change your signaling transport to use standard UDP or TCP instead of TLS

If a call is being labeled as spam is important to understand that this spam indication is being applied by the called parties carrier. There is unfortunately nothing that Clearfly can do to remove or influence this spam rating.

The FCC has published a useful guide with suggestions to try and prevent legitimate calls from being blocked, and which also contains links to feedback and/or removal sites for many different carriers. That guide can be found here.