Same provider but different trunks and DID's - Voip.ms

Hi guys,

Still trying to figure out how to make voip.ms trunks to work on a local FreePBX machine.

I’ve tried everything I know, even changed POP, but no registration happens on Voip.ms side.

Their support said that they don’t detect traffic from me.

Both trunks that I have from them are SIP, one works ok, new one won’t, it shows registered on Asterisks info!

Anything special needs to be done on the system to make trunks from same provider work?

Thanks.

First, you shouldn’t need two trunks to the same provider, just route all your DIDs to the same (sub)account. If this doesn’t work, report what (if anything) appears in the Asterisk log on an attempted incoming call, what the caller hears, and what gets logged at VoIP.ms.

Next, assuming that you want two trunks, are they configured identically, except for username and secret?

That is bizarre, given that it appears registered from your end. Conceivably, you are registering to a different account. To troubleshoot this, set Expiration short, e.g. 120 seconds, so you don’t have to wait long for a re-registration. At the Asterisk command prompt, type
pjsip set logger on
wait for a re-registration, and look in the Asterisk log at the REGISTER request and their responses. If you have trouble interpreting them, paste the relevant section of the log at pastebin.com and post the link here.

pjsip has a feature to associate an incoming call to the proper trunk, “Send Line in Registration”. However, this is on by default so it shouldn’t be a problem. Even if this isn’t working, it’s not a problem unless the trunks have different Context, codecs, etc.

Thanks for your time Stewart. Yes, I needed to separate them for the billing purposes.
They are both SIP with identical settings, POP’s but different credentials.

I will post debug logs tomorrow.

Question to Stewart. Since my voip.ms trunks just sip, does pjsip set logger on work? Asking it as I didn’t see my sip trunks during debug.

I double checked trunk entries and provider settings - all match with other working account!

When run sngrep, registration onto new account never happens and I saw lots of OPTIONS instead of REGISTER.

This is how it looks like on working account

In the Asterisk info module I also observe these:


Why are you using chan_sip? There are a lot of details that may be relevant here that I don’t know:
How often does it re-register on auth failures?
Does it give up after some number of failures?
Does “No Authentication” include no response or other conditions that preclude sending auth?

Unless you have a strong reason for using chan_sip, please delete the trunks and set them up as pjsip.

On the pjsip General tab, fill in Username, Secret and SIP Server. Leave everything else default.
On the Advanced tab:
Expiration: 120 (so we don’t have to wait long for re-registration if we need to capture traffic)
Contact User: (same as what you had after the / in your chan_sip Register String, if anything)
From Domain: (same as SIP Server)
From User: (same as Username)

Here is what I see now in asterisk -vvvr after set one as pjsip:

res_pjsip_outbound_registration.c:1383 handle_registration_response: 403 Forbidden fatal response received from ‘sip:sanjose2.voip.ms’ on registration attempt to ‘sip:acc#@sanjose2.voip.ms’, retrying in ‘30’ seconds

Extended version:

[2023-08-10 19:54:57] WARNING[64016]: res_pjsip_outbound_registration.c:1383 handle_registration_response: 403 Forbidden fatal response received from ‘sip:sanjose2.voip.ms’ on registration attempt to ‘sip:myacc#@sanjose2.voip.ms’, retrying in ‘30’ seconds
<— Transmitting SIP request (443 bytes) to UDP:208.100.60.41:5060 —>
OPTIONS sip:myacc#@sanjose2.voip.ms SIP/2.0
Via: SIP/2.0/UDP my IP:5060;rport;branch=z9hG4bKPjc2310d39-1a28-4b42-a7f3-4acc2749df58
From: sip:myacc#@sanjose2.voip.ms;tag=cb5eb0c3-f361-4d82-bb00-2550d84a6721
To: sip:myacc#@sanjose2.voip.ms
Contact: <sip:myacc#@my IP:5060>
Call-ID: 07bba2e2-e24d-4848-9db0-63a90f7c87c4
CSeq: 52851 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-16.0.40.4(18.19.0)
Content-Length: 0

I just tested to sanjose2 and was able to register ok. In the VoIP.ms portal, go to Manage Sub Accounts.
Confirm that you don’t have an IP or POP restriction set. Check username. If all correct, generate a new password and paste it into Secret for the trunk.

1 Like

Yes, all seems to be correct, I’ll reset password.

It’s actually not a sub account. It’s its own, independent.

I even changed “Current SIP/IAX Password” for a new random. Do codes affect registration?
On provider side, it only checked G.711U, G.729a.

I GOT it! It was SIP/IAX password. It actually different from the account.

Does anyone know optimal time for re-registration? Is it dictated by SIP provider?

The optimal time is never, i.e. use a static address and configure that on the provider.

If the provider doesn’t like your proposed interval, they should be overriding it anyway.

Otherwise it depends on things like whether your IP address is unstable, whether it is needed to keep dynamic router rules up (although qualify is normally used for that) and how much bandwidth can you spare for it., etc.

So, most of my trunks are 120s for re-register now. Are you saying that if it works then it means that ether they are okay with it or their servers override my values anyway?

My FPBX machine is behind a dynamic public IP (Spectrum), which I’d say never changes, I have this place for 3 years… My PBX now serves 2 households, I have my softphone with me when I’m on the field and VPN is always on.

It’s expensive CPU’wise and bandwidth’wise to do these SIP packets, ACK, etc. exchanges every 2 minutes. Just my though.

The registrar can reduce the expiry time and it can also, effectively, force expiry times up, but not beyond one hour. The latter is done by rejecting with an offer of an acceptable minimum value.

I’d suggest that 120 seconds is rather aggressive, in your environment. The default is one hour, although there may be reasons for forcing lower values.

Ok, I will test higher values, I too think it’s more frequent than required.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.