Log in Register

Login to your account

Username *
Password *
Remember Me

Create an account

Fields marked with an asterisk (*) are required.
Name *
Username *
Password *
Verify password *
Email *
Verify email *
Captcha *

You are not getting any response to your SIP requests

Cause: Your firewall is blocking the outbound SIP requests to GOUP.

Open ports on your firewall as per our IP address whitelisted

Cause: Your PBX cannot access a DNS server on the public internet.

We will push the Termination URI that you specified on your trunk to public DNS servers. You either need to configure a local DNS server to resolve this URI or allow your PBX access to public DNS servers.

Cause: You are not putting the Termination URI in the Request-URI on INVITE requests that you send to GOUP.

If your request URI doesn’t reference the Termination URI you configured on your trunk, we will view your SIP messages as malicious and drop them. The Request-URI you send us needs to be sip:<e.164 formatted   phone number>@<your termination URI>

You are getting 403 Forbidden responses to your INVITE requests

 Cause: There is an ACL on your trunk and you are sending us INVITE requests from an IP address not on that ACL.

 Check the received parameter on the Via header of the 403 response that we send you: it will tell you the IP address from which we are receiving your SIP request. Either fix local routing so that you are sending us SIP from an address already in your ACL or add this other address to your ACL

 Cause: There is a Credentials List on your trunk, and your INVITE’s Authentication Digest is incorrect due to wrong username/password

 Confirm that your username/password matches one in your Credentials List. A test is to remove the Credentials List and see if the call works with just an ACL.

Tip: You can tell which cause it is by which INVITE is getting the 403. If it is the initial, "digest-less" INVITE, the problem is most likely the ACL not matching. If it is the INVITE with an Auth digest (after a 407 Authentication required), the problem is most likely the credentials not matching.

The call fails with a ‘403 Invalid Caller ID’ error

Cause: GOUP accounts are required to use a GOUP-validated Caller-ID.

Be sure you use you DIDs or CLI numbers.

Be sure to set the DID number to either a GOUP number, or a verified CLI number, in your GOUP account.

If a Remote-Party-ID is included in the INVITE, be sure it is also set to a valid Caller-ID, as described above.

The call fails with a `503 Trunk concurrent call limit exceeded’ error

Cause: You are using a Trunk on a GOUP Account, and you have 2 concurrent active calls.

 You can remove this restriction by upgrading your Account with more channels

 Alternatively, reduce the number of concurrent calls on your GOUP Trunk.

The call connects, there is two-way audio, but the call drops after 20 or 30 seconds

Cause: You SIP communications infrastructure is incorrectly Sending an ACK to GOUP using an IP address other than the Contact header's IP address found in GOUP's 200 OK in the Request-URI. This causes GOUP to not process the ACK, so the transaction times out after 30 seconds, and the call is torn down via a BYE sent from GOUP's side to both sides of the call.

Your SIP communications infrastructure should use the IP address in the Contact header of GOUP's 200 OK in the Request-URI of the ACK, and send the ACK to the IP address in the Record-Route header of the same 200 OK.

Cause: Your SIP communications infrastructure is incorrectly adjusting/replacing the GOUP Private IP addresses in the URI and headers of the ACK they return with their own Public IP addresses. This is causing GOUP to route the ACK back to the SIP communications infrastructure, and as such not process it. Because the ACK is not processed, GOUP (correctly) times out and tears down the call.

Your SIP communications infrastructure should never replace any of GOUP's own IP addresses; they should only adjust their own IP addresses.

On Origination calls (from SIP to your PBX): there is no audio and the call drops after 20 or 30 seconds

Cause: Your SIP infrastructure is replacing a GOUP-specific private IP address in a stacked Via header with a different IP address in a 200 OK. This is likely due to a Global replacement of certain private IP ranges. This will cause the 200 OK to be dropped inside GOUP's infrastructure, preventing an ACK from being sent, and causing your infrastructure to terminate the call.

Your SIP infrastructure should not change the IP addresses in the Via headers when responding to an INVITE from GOUP.

On Origination calls (from SIP to your PBX): there is two-way audio, but the call drops after 20 or 30 seconds