Vodafone Greece SIP Trunk

[pkostovasilis]

We have received the following info from Vodafone Greece SIP Provider regarding a sip trunk with a router on premises, and a 3cx v15.5 SP6 installed in Windows Server 2012 R2

SIP Early Offer or Delayed Offer or Early Media support=Early Media

Transport protocol, TCP or UDP =UDP ports 10000-30000

VoIP Codec support =G711 a law

FAX method=passthrough

Any authentication needed on SIP trunk=Line id // ip peer to peer

Any registration needed on SIP trunk=Registration for one account user & pass

Autoframing=yes

Canreinvite=no

Ignoresdpversion=yes

Type=peer

Insecure=port,invite

Dtmfmode=inband

Disallow=all

Allow=alaw:101

Qualify=500

Nat=no

session-timers=refuse

Should i use SIP Trunk or SIP Connect UDP ?
Can you please help me understand the differences?


Using generic SIP Trunk Template with no authentication the inbound and outbound calls seemed to function normally.
But the first day of fully operation, the customer said that they were unable to make outbound calls for about 2-3 minutes and then it started working again. This happens 3-4 times per day for about 3 minutes, infrequently. Incoming calls, DO work during this period.
Vodafone's trace showed that when this happens, the vodafone router sends and authentication request and doesn't get a response(vodafone_problematic.png). The strange thing is that while the sip trunk works without problems these requests are answered as expected (vodafone_normal.png).

The 3cx event log entry is

Call or Registration to 6936_____22@(Ln.10000@Vodafone SIP Trunk) has failed. 192.168.0.42 replied: 404 Not Found; from IP:192.168.0.42:5060

After conferencing with the vodafone technician he suggested that there is a problem with the spanning tree in the internal network and the connection between the 3cx server and the Vodafone gateway gets lost. We changed the port that the vodafone port was connected from trunk to access and we are waiting to see if this resolves the issue.
Does anyone have encountered any similar problem?

 

[YiannisH_3CX]

Hello @pkostovasilis

Should i use SIP Trunk or SIP Connect UDP ?
Can you please help me understand the differences?

The Generic SIP trunk template included in the 3CX phone system is a template that is configured to use the most common settings providers use. This is to help you configure a non supported provider with some pre-configured options that most providers are using. This does not mean that all providers use the same settings and that you will not have to perform any changes.
By using the SIP connect template with a SIP connect compliant provider you have a higher probability that these settings will work without any changes but again this is not guaranteed.

Since calls work both inbound and outbound you should be ok with the way the trunk is configured.
I do have one question however regarding the configuration. You mentioned using the SIP trunk template without authentication but your provider requests authentication on each call. Did you fill in a username and password?

Regarding the issue you are facing you need to see what happens in the phone system the time of the issue. The capture from the providers side shows authentication messages being sent but not replied to. You need to check if those messages are actually hitting the phone system and if the phone system replies.
If the messages do not reach the phone system or the phone system replies to the messages but the reply does not reach the providers router then the issue is network related.
If non of the above is happening you need to look deeper into the 3CX logs and see what is causing this.

 

[pkostovasilis]

Dear Yianni,
thank you very much for your repsonse.
In the sip trunk General Tab, i have selected Type of Authentication : Not Required - IP based but have filled the below field with the provider's username and password.
When we first tried to setup authentication either for outbound only or for all calls, the registration was failing. The Provider's support informed us that registration is only required when making an outgoing call and that when the sip trunk is operational, they DO receive the authentication from 3cx.
I know we should run a trace in the server side as well, but because the time window of the problem is too small (2 or 3 minutes) we don't have enough time to connect to the server and run the wireshark capture before the problem is self-resolved.
So far we haven't experienced the issue yet (2-3 times the customer thought they were unable to make external calls it was because they were using the prefix of the previous phone system to make an outgoing call) after changing the port from trunk to access.
Thank you again for your reply
Best regards,

 

[YiannisH_3CX]

If you face the issue again you could run a Tshark capture that will split the capture into smaller files and prevent the server or wireshark from crashing. You can leave this running until the issue replicates again and then look at the file with the closest timestamp to the issue. Hopefully though the issue is now resolved. Keep us updated.

 

[pkostovasilis]

Just after my answer, i got a call from the customer that this happened again.
We opened a command prompt a ping -t the vodafone device and when this happened again the ping was not interrupted, which means the network connection between the two devices was not an issue.
The registration issue is bothering me too. I have never setup a sip trunk before (only voip providers that give you a public IP or fqdn to register to) so it concerned me too when registration initially failed. When i switched it to "not required /ip based" everything worked (while leaving the credentials in the appropriate fields as well) so i thought it was normal.
Anyway i will try to wireshark it to see if i can dig deeper

 

[pkostovasilis]

In the activity log i get similar messages when we are facing the issue

10/24/2018 4:12:50 PM - Exception: ParseException E:\jenkins\workspace\15.5SP6\SPBuild\Sources\3rdParty\Resiprocate\rutil/ParseBuffer.hxx:230, Parse failed unexpected eof in context: 21025____66 ^ @ E:\jenkins\workspace\15.5SP6\SPBuild\Sources\3rdParty\Resiprocate\rutil/ParseBuffer.hxx:230 10/24/2018 4:12:50 PM - Call to T:Line:10000>>21025____66@[Dev:sip:[email protected]:5060] from L:825.1[Extn:7119] failed, cause: Cause: 404 Not Found/INVITE from 192.168.0.42:5060

In this thread ( https://www.3cx.com/community/threads/activity-log-parseexception-error-in-15-5-sp-4.56779/ ) they say this happens when yealink phones try to call a number that does not exist or there are no available routes.
At first i thought that maybe something was wrong in the outbound parameters of the sip trunk, but in that case we wouldn't be able to make any outbound calls.
Another thing that we are considering is to put the ip of the device provided by vodafone as the default gateway in 3cx server. What do you think?

 

[YiannisH_3CX]

The registration issue is bothering me too. I have never setup a sip trunk before (only voip providers that give you a public IP or fqdn to register to) so it concerned me too when registration initially failed. When i switched it to "not required /ip based" everything worked (while leaving the credentials in the appropriate fields as well) so i thought it was normal.

If you have credentials in the Auth ID and Password fields then the 3CX phone system will authenticate when requested so that is OK.
The fact the you could not register though is weird as communication seems to be there between the server and router.

Another thing that we are considering is to put the ip of the device provided by vodafone as the default gateway in 3cx server. What do you think?

Do you have a second NIC dedicated to connecting with the Vodafone router?

 

[pkostovasilis]

Dear Yianni,
we tried with a dedicated NIC card and the problem didn't occur anymore.
Meanwhile the customer noticed even though the sip trunk router was in a separate network, it's old IP was still answering to pings, so we found out that there was another device (that was turned off during initial configuration of the SIP Trunk) that had the same IP. This was probably the reason why we noticed these disconnections of the sip trunk.
We will try again on the same network with different IP and hopefully the issue won't happen again.
Anyway thank you for your help.
Best regards,

 

[YiannisH_3CX]

Glad i could assist. Let us know if further assistance is required