Auth

Management Customer [Customer Name] Auth

Under the Auth tab, configure IP or SIP (Username/Password) Authentication for users.

Global IP and SIP Authentication

Both IP and SIP Authentication may also be configured and managed for Customers and Carriers under Global IP Authentication or SIP User Authentication.

IP Authentication

When you enable IP Authentication, you associate the IP of a customer switch to their account. This add a layer of security by ensuring the calls are coming from a trusted source.

Newly added IP immediately marked as Blocked under IP Authentication

This occurs because call requests were sent from the new IP before it is authorized. As a result, ConnexCS fraud detection blocked the unauthorized IP in the firewall. Attempted calls from this IP will not be completed. To resolve the blocked IP, go to Setup Advanced Firewall. Select the blocked IP, then delete it from the firewall. This unblocks the IP, but it will take up to 15 minutes for the change to become active in the switch. See Threat Detection for more details.

Enable IP Authentication

To enable, click the next to IP Authentication:

Click each tab to view configuration details

BasicAdvancedCodecsParameter Rewrite

• IP: Enter the IP(s) of the customer switch. (FQDN can be used for Ingress only switches.)

• Switch Direction: The available options are from the perspective of the customer switch (PBX, dialer, etc), and describe how that switch interacts with the ConnexCS switch. For switches that send and receive calls from ConnexCS, there will need to be separate entries for each direction.

  Ingress: This switch receives calls from ConnexCS. (Note: when selected, this gives the option of using the FQDN rather than the switch IP.)

  Egress: This switch sends calls to ConnexCS.

• Channels: Set the maximum number of concurrent calls for this switch.

• Flow Speed: Set the Calls Per Second (CPS) (0 = unlimited calls).

  

• Manufacturer and Version: These references fields allow you to enter the customer switch Manufacturer and Version if desired (these fields are not functional; they are informational only).

• Protocol: Select the protocol for SIP (call signaling) RTP (transport/audio).

  UDP: SIP and RTP are unencrypted and transported over UDP.

  TCP: SIP is sent over TCP, RTP over UDP.

  TLS: SIP is sent over TLS (TCP), RTP over UDP.

  TLS & SRTP: SIP is sent over TLS (over TCP), RTP is encrypted with SRTP.

  SMPP: SMPP, for SMS, is not currently supported.

• Port: Default = 5060. If using TLS protocol, this should be set to 5061.

• Dial Pattern: the default selection is the industry standard.
• CLI Prefix, Tech Prefix, Strip Digits: Do NOT Use these fields. Use the Parameter Rewrite tab to modify numbers.
• Bandwidth, Force From: Do NOT Use these fields.
• Username, and Password: Set when sending calls out (egress switch direction) to a remote system, setting this will allow the ConnexCS switch to operate as a client, or UAC. Not typically recommended unless the customer has a very specialized system.
• Force NAT: Forces the switch to read the IP address the traffic was received from, not the IP in the SIP packet. (See Far-End NAT Traversal for more details on how ConnexCS handles NAT for SIP.)
• Intercept Reinvite: The only situation where this is recommended is when a customer's equipment doesn't support REINVITES. Enabling this may correct issues with dropped calls by having ConnexCS generate the REINVITES, which can help keep calls up if they are being disconnected by the far-end switch.
• Outbound Proxy: Enter an IP of a Proxy server for calls to route to, before being sent to the carrier. This rewrites the UAC IP in the VIA field of the SIP header. This reduces management overhead as a customer only needs to authorize the single IP. Additionally, multiple addresses can be load balanced using the AnyEdge system.
• Flags: Set CLI Authentication for situations where Accounts are unable to use Tech Prefix to differentiate customers using the same IP.

All Codecs are supported unless specifically set as "Restricted" here.

The Parameter Rewrite tab is used to manipulate data as it comes into the system. It is most useful when you need to create automatic replacements for destination numbers or CLI, so a number is formatted in the appropriate E164 format.

1. Click the +.
2. Type: Select the parameter to modify.
3. Current: Enter the prefix for the destination number, or the CLI.
4. New: enter what should replace the current information.
5. Use the Testing Input field to verify the replacement is working as expected.
6. Click Save when done.
7. If a parameter rewrite has already been created, you will have the ability to test it from the main tab.

Example: International calls coming in with a + should be replaced with a specific country code.

 

---

IP Authentication Audit Log

After IP Authentication has been setup, click on the IP to view configuration, and at the top of the page you can click "View Audit Log" to view changes specific to these settings.

SIP User Authentication

When SIP Authentication is enabled, ConnexCS will reject the initial SIP INVITE with a "407 Authentication Required". This message includes a 'nonce' (a uniquely randomly generated number, which has been hashed). The customer switch will send appropriate authentication information to ConnexCS, which will connect the call.

Generic SIP Trace showing the Challenge Response:

 

Enable SIP User Authentication

To enable, click the next to SIP User Authentication:

Click each tab to view configuration details

BasicCodecsParameter RewriteVoice MailLatency

• Username: This will be the Username used for SIP authentication (must match configuration on the customer UAC). If The Customer has Internal Number Block set on the Main tab, the Username may only be selected from available extensions. If a Username is already in use on the Account, they will get an error "Duplicate User Detected".
• Password: Must match configuration on the customer UAC.
• Channels, Flow Speed, Bandwidth; Do NOT use these fields.

• Protocol: Select the protocol for SIP (call signaling) RTP (transport/audio).

  UDP: SIP and RTP are unencrypted and transported over UDP.

  TCP: SIP is sent over TCP, RTP over UDP.

  TLS: SIP is sent over TLS (TCP), RTP over UDP.

  TLS & SRTP: SIP is sent over TLS (over TCP), RTP is encrypted with SRTP.

  SMPP: SMPP, for SMS, is not currently supported.

• IP Whitelist: Enter specific IPs or use CIDR notation to specify an entire subnet.

• NAT/SIP Ping: Set behavior of pings sent from ConnexCS back to the customer through their firewall to their UAC. This helpful when there are remote agents connecting into the switch.

  Disabled: No pings are sent

  Enabled: Send UDP ping every 60 seconds, helping to keep some longer calls (1800 or 3600 seconds) up.

  Enabled (Timeout): Send UDP ping every 60 seconds and disconnect the call (terminate registration) if the pings aren't returned.

• Retain DID: When Enabled, inbound calls will retain the destination number (DID) the call is sent to in the system, rather than use the SIP Username.

• Smart Extension: Calls are sent to the Class5, not Class4 infrastructure. This feature is currently in Alpha and is not recommended.

  

All Codecs are supported for the SIP user unless specifically set as "Restricted" here.

The Parameter Rewrite tab is used to manipulate data as it comes into the system. It is most useful when you need to create automatic replacements for destination numbers or CLI, so a number is formatted in the appropriate E164 format.

1. Click the +.
2. Type: Select the parameter to modify.
3. Current: Enter the prefix for the destination number, or the CLI.
4. New: enter what should replace the current information.
5. Use Testing Input field to verify the replacement is working as expected.
6. Click Save when done.
7. If a parameter rewrite has already been created, you will have the ability to test it from the main tab.

 

If Voice Mail is enabled, you can set which email address receives messages, reset the Voicemail Password, and view and delete current messages. See Voicemail for information on accessing Voicemail.

If NAT/SIP pings are enabled, the Latency tab will be available at the top of the SIP user screen, and displays the status of the SIP pings, and latency based on those pings. This can be helpful for troubleshooting audio problems.

---

Reset SIP Password

Click the Password key next to the SIP user to reset the password. Optionally, use the Generate Password button to generate a random and secure SIP password. Make sure you Copy Text and provide this information for configuration as this password can't be retrieved after it has been set.

Customers using the Customer Portal can rest their SIP Passwords in Authentication.

SIP Password security

SIP passwords are a requirement of the SIP protocol but can present security risks for a provider. They must be configured in ConnexCS when SIP authentication is setup but are not available for providers to retrieve afterwards. Providers should generate a unique SIP password for each SIP user and send that to the customer. This gives the customer the responsibility of keeping track of the password and keeping it safe. Additionally, the unique password will allow for traceability if the customer's system is ever compromised.

Send message to SIP Users

Use the Send button next to the SIP User to send a SIP message to the end device which will flash on the phone.

Use Case for NAT/SIP Pings

Troubleshooting Scenario The Customer reports they can register and make outbound calls, but they are unable to receive inbound calls.

What is happening In a typical configuration, a packet is sent from the customer UAC out through a NAT/firewall, and then the packet is delivered to the UAS:

graph LR A(Customer switch) --> B(NAT/firewall) B --> C(ConnexCS switch) style A fill:#ECEFF1,stroke:#4051b5,stroke-width:4px style B fill:#ECEFF1,stroke:#4051b5,stroke-width:4px style C fill:#ECEFF1,stroke:#4051b5,stroke-width:4px

• When a packet goes out, a hole is punched in the firewall, and the source port is recorded. When a packet is returned on that port, the firewall knows to deliver back to the UAC.
• This works well when using TCP, which sends regular keep-alive packets.
• UDP does not send keep-alives (no connected state as with TCP). SIP does maintain a connected state, registration, but may have long periods of inactivity.
• Without regular traffic passing between UAS and UAC in the form of keep-alives/registration (a normal occurance), NAT will eventually time out and shut down the connection.
• Enabling UDP or SIP pings can demonstrate to the NAT/firewall that the signaling path is still valid and in use.