Solved nexVortex Trunk stopped working with R9

[Richard10]

After updating to R9, nexVortex no longer is able to send inbound calls. Outbound is still working.

3CX is replying to the inbound request with a "SIP/2.0 407 Proxy Authentication Required", I have switched the trunk to not require auth (they use IP based anyway) but the result is the same.

This is a generic trunk, and has been in use for 6+ years, obviously converted to v20 last year.

The "Check SIP Trunk" shows all good, but "Inbound Call Test" fails.

 

[YiannisH_3CX]

Hello Richard,

I have sent you a DM

 

[Colorado VoIP]

i'll be curious as to the result on this, we have some nexvortex users.

 

[Kevin Attard Compagno]

You should go through this to get a primer of the hows and whys of these types of issues:
https://www.3cx.com/docs/voip-provider-checker/

If the PBX is unable to identify which trunk is delivering the call (particularly if you have multiple instances of the same IP Address for IP-based trunks), this would be the expected behaviour.

 

[Colorado VoIP]

After updating to R9, nexVortex no longer is able to send inbound calls. Outbound is still working.

3CX is replying to the inbound request with a "SIP/2.0 407 Proxy Authentication Required", I have switched the trunk to not require auth (they use IP based anyway) but the result is the same.

This is a generic trunk, and has been in use for 6+ years, obviously converted to v20 last year.

The "Check SIP Trunk" shows all good, but "Inbound Call Test" fails.

Richard10, did some experimenting on our in-house system and it looks like changing the main number on the trunk to full e164 format does the trick. also running 10 digit DID with a * in front was a workaround, but we saw that same proxy authentication required message duplicating settings from customer trunks on the generic template.

the U9 inbound call test only caught one other thing but the call flowed ok. Try changing to +1 on trunk.

 

[Richard10]

Richard10, did some experimenting on our in-house system and it looks like changing the main number on the trunk to full e164 format does the trick. also running 10 digit DID with a * in front was a workaround, but we saw that same proxy authentication required message duplicating settings from customer trunks on the generic template.

the U9 inbound call test only caught one other thing but the call flowed ok. Try changing to +1 on trunk.

Adding the + seems to have fixed it! Thanks for taking the time to troubleshoot that. I was doing a tcpdump on the firewall in front of the PBX and the SIP packets don't have a + so something changed in R9 related to that. Easy fix, nice find.

 

[Colorado VoIP]

Adding the + seems to have fixed it! Thanks for taking the time to troubleshoot that. I was doing a tcpdump on the firewall in front of the PBX and the SIP packets don't have a + so something changed in R9 related to that. Easy fix, nice find.

i noticed putting the number in again under a DID with that * (instead of the main trunk number) made it work, so then I tried just making the main trunk number *DID and it worked, then +1 after reviewing wireshark capture. I'm not good at wireshark at all but I saw the number being presented with that +1 on the U9 update. but I'm glad that worked for you, I am going to implement this some time this weekend for the small subset of customers on nexvortex and make sure calls still flow on U8, then manually update them to U9 and turn back on auto updates.

 

[Richard10]

So the INVITE does not have the + but the To: does. Perhaps they switched to checking the To:
Putting *DID is interestingly what BCM one recommends in their documentation to cover both national and e.164.

If they change the behavior back to what it was before (unlikely?) having *DID or both DID and +DID would cover either approach.

 

[YiannisH_3CX]

So the INVITE does not have the + but the To: does. Perhaps they switched to checking the To:
Putting *DID is interestingly what BCM one recommends in their documentation to cover both national and e.164.

The PBX will read the called number from the SIP header specified in the template. If you have not made any changes to the template then you should have the same issue on Update 8. There were no changes to this area in Update 9. The other option is that NexVortex changed the number format from their end recently causing this issue.

The error you are getting is related with call source identification so if the number formats do not match then you will get the error as the PBX does not know to which trunk to match the call.

 

[Richard10]

Thanks so much, and for anyone finding this thread, the + at the front of the DID (more specifically E.164 format) is the fix as discovered by Colorado VOIP. It was pointed out to me by YiannisH that the generic template is set to check the To: field. Not sure why the coincidence, but here we are

 

[Richard10]

Since I don't like coincidences, I called and asked nexVortex if they changed their packets. They said "No. And we just pass on what we get." I think he is incorrect. I looked and I can see in the event log that it basically broke hours before I upgraded the PBX. Around 10am PST some of their proxies started sending calls in E.164 format. By 11:30am PST no inbound calls worked. Because it's a school on summer break the few staff there didn't even notice. I then coincidently upgraded to R9 that night. Crazy coincidences, the bane of IT.

 

[Colorado VoIP]

Since I don't like coincidences, I called and asked nexVortex if they changed their packets. They said "No. And we just pass on what we get." I think he is incorrect. I looked and I can see in the event log that it basically broke hours before I upgraded the PBX. Around 10am PST some of their proxies started sending calls in E.164 format. By 11:30am PST no inbound calls worked. Because it's a school on summer break the few staff there didn't even notice. I then coincidently upgraded to R9 that night. Crazy coincidences, the bane of IT.

typical response... "no we didn't change anything" hahaha. uh.......the packet captures and logs prove otherwise.

 

[N_G]

And one that we hear all the time. With every update, run the SIP voip provider compatibility checker its pin points any issues. (there might still be other things but this is a great automated starting point)

 

[Colorado VoIP]

And one that we hear all the time. With every update, run the SIP voip provider compatibility checker its pin points any issues. (there might still be other things but this is a great automated starting point)

yeah i can literally see in the call logs that mid-day june 15th nexvortex or bcm one, whatever they call themselves today, started sending +1 on all the calls lol!!