Solved Multiple Invites from the same call in under a second

[DtotheAmbrose]

I am chasing down a problem we have with outbound calls which has started up today (we switched over from elastix to 3cx recently)

3cx V15.5
Vitelity is the provider
Yealink 32/38 phones which have the newest firmware

When we call outbound we get a rejection from Vitelity as the outbound call is triggering 2 instances with a second of each other. Vitelity says "This caused our system to think these were two different calls and they failed."

Oct 20 12:09:00.835 PM 198.xxx.xxx.93 > 64.2.142.188 INVITE sip:[email protected]:5060 SIP/2.0
Oct 20 12:09:01.331 PM 198.xxx.xxx.93 > 64.2.142.188 INVITE sip:[email protected]:5060 SIP/2.0

This is causing vitelity to reject the calls with a 486 error. Anyone run into this before and have a fix?

Thanks

 

[leejor]

If you look at the 3CX Activity Log, of the call, does it look "normal" no double calls, from the point when initiated by the set? Do you have any other type of sets, or outbound routes, that you can compare against?

When did this start? Were any changes made to anything just before this began? Was it working correctly, for a while?

Some of the logs that you have omitted, may provide more of a clue as to what it happening.

 

[DtotheAmbrose]

This is the first day we have used the 3cx server in a live environment. We had tested it for a week with in-bound and outbound had no problems.

We ported over 2 numbers from comcast which completed this morning. This did create a problem with a credentials dont match error which required deleting and reentering the SIP trunk which got us going again.

Here is the entry before it started acting up on the outbound calls i posted above:

10/20/2017 12:01:42 PM - [CM102001]: Authentication failed for AuthFail Recv Req REGISTER from 199.48.164.78:60744 tid=ac536267e37b8b08658ff4f9d2574b14ec32c5bc86e1d13c48193645101678 Call-ID=03238ae0e1b2e736408789dc917cb09b: REGISTER sip:198.xxx.xxx.93:5060 SIP/2.0 Via: SIP/2.0/UDP 199.48.164.78:60744;branch=z9hG4bKac536267e37b8b08658ff4f9d2574b14ec32c5bc86e1d13c48193645101678 Max-Forwards: 70 Contact: 8001 <sip:[email protected]:60744> To: 8001 <sip:[email protected]:5060> From: 8001 <sip:[email protected]:5060>;tag=478cf3549c07e0c3c1c2360bf192e8f1 Call-ID: 03238ae0e1b2e736408789dc917cb09b CSeq: 2 REGISTER Expires: 1800 Proxy-Authorization: Digest username="8001",realm="3CXPhoneSystem",nonce="414d535c0ffad91698:634632251fab383f603e266ae75bb8ce",uri="sip:198.xxx.xxx.93:5060",response="1c54c81281dcfb3ab3c55ae81c2f49ef" Content-Length: 0 ; Reason: Credentials don't match, check that authorization-ID and password match the ones in extension settings

and the one right after:

10/20/2017 12:24:32 PM - PBX has dropped a message with 'User-Agent: friendly-scanner' from IP 185.107.83.48 because it is on blocked UAs list

I reviewed the entire log looking for anything else that could be causing it to occur but I must be missing something.

 

[DtotheAmbrose]

I forgot to add one thing. If I refresh the registration with vitelity the outbound calls work again.

 

[DtotheAmbrose]

I think this may be more of a problem with the provider. We just lost the outbound calls again with a different errors

This happened first.

10/20/2017 2:05:23 PM - Call to T:Line:10001>>1@[Dev:sip:[email protected]:5060] from L:44.1[Extn:100] failed, cause: Cause: 403 Forbidden/INVITE from 64.2.142.17:5060
10/20/2017 2:05:23 PM - [CM503003]: Call(C:44): Call to <sip:[email protected]:5060> has failed; Cause: 403 Forbidden/INVITE from 64.2.142.17:5060

We re-registered the trunk and the outbound started working again. 20 minutes later we lost outbound again

10/20/2017 2:24:14 PM - Call to T:Line:10001>>1xxxxxxxxxx@[Dev:sip:[email protected]:5060] from L:48.1[Extn:101] failed, cause: Cause: 486 Busy Here/INVITE from 64.2.142.188:5060
10/20/2017 2:24:14 PM - [CM503003]: Call(C:48): Call to <sip:[email protected]:5060> has failed; Cause: 486 Busy Here/INVITE from 64.2.142.188:5060

When the IP address switches on Vitelity's end looks to be when this comes up. I submitted a ticket with them asking for input on this.

 

[leejor]

The first two logs would appear to be indicating hacker activity. (8001 & 'User-Agent: friendly-scanner') and nothing to do with the outbound call issue.

10/20/2017 2:05:23 PM - Call to T:Line:10001>>1@[Dev:sip:[email protected]:5060] from L:44.1[Extn:100] failed, cause: Cause: 403 Forbidden/INVITE from 64.2.142.17:5060
10/20/2017 2:05:23 PM - [CM503003]: Call(C:44): Call to <sip:[email protected]:5060> has failed; Cause: 403 Forbidden/INVITE from 64.2.142.17:5060

These logs seem to indicate that the numbers you are attempting to dial are not permitted by the provider, hence the "forbidden"

We ported over 2 numbers from comcast which completed this morning. This did create a problem with a credentials dont match error which required deleting and reentering the SIP trunk which got us going again.

I'm not certain why porting numbers to a provider that you already were using, would cause credential issues, I'm assuming that the numbers were ported to Vitality.. But, it would seem to have something to do with , perhaps, a difference between the original trunk settings, and changes that were made.

 

[NickD_3CX]

I agree, the issue seems to be with the Provider rejecting the call.

On a slightly different note, I wanted to point out that the interop between 3CX and Vitelity was done based on their non-authentication model. Instructions that we have published about getting Vitelity to work with 3CX can be found here: https://www.3cx.com/docs/vitelity-usa-sip-trunk/

 

[DtotheAmbrose]

After going back and forth a few times with Vitelity here is the solution,

The settings provided from Vitelity to enter into the SIP trunk are a little off. For the outbound calls you need to setup a different trunk which does not register with Vitelity. What was happening is our account would try to register with them on each call outbound and would trigger a fault and it would look like multiple calls within a second causing the provider to block everything.

 

[Stephen Quam]

I have used Vitelity for quite some time. We had to have 2 trunks even with Asterisk for it to work correctly. I would strongly encourage the ip based authentication model. That is if you have a static ip.