SIP Trunk Header Info Problem

Status
Not open for further replies.

benratty

Forum User
Joined
May 23, 2011
Messages
77
Reaction score
0
I have 4 systems all on same 3CX versions all using Gamma SIP trunks, all have the exact same firewall versions, Draytek 2860 all with the same firmware version.

1 of these systems has started to play up, it is sending the following when making outbound call

06/08/2018 13:25:57 - NAT/ALG check:L:890.2[Line:10001>>PHONENUMBER] RESPONSE 200 on 'INVITE' - some of SIP/SDP headers contain inconsistent information or modified by intermediate hop
Media session IP ('c=' attribute) is not equal to the IP specified in contact header:
Media session IP: Media IP from SIP trunk provider
Contact IP:Signalling IP from SIP trunk provder (as setup in trunk on 3CX)
Media session IP ('c=' attribute) is not equal to the SIP packet source(IP:port):
Media session IP: Media IP from SIP trunk provider
Received from: Our external IP address

Inbound call

06/08/2018 13:25:10 - Call to T:Extn:1216@[Dev:sip:[email protected]:5488;rinstance=1909b87ab6110656,Dev:sip:[email protected]:5060;rinstance=1-elm92gdgbpawasiwz6gvvlm1b5wbqz28;inst="0639386f"] from L:884.1[Line:10001<<PHONENUMBER] failed, cause: Cause: 408 Request Timeout/INVITE from 127.0.0.1:5488
06/08/2018 13:25:10 - NAT/ALG check:L:884.1[Line:10001<<PHONENUMBER] REQUEST 'INVITE' - some of SIP/SDP headers may contain inconsistent information or modified by intermediate hop

Media session IP ('c=' attribute) is not equal to the IP specified in contact header:
Media session IP:Media IP from SIP trunk provider
Contact IP:Signalling IP from SIP trunk provder (as setup in trunk on 3CX)
Media session IP ('c=' attribute) is not equal to the SIP packet source(IP:port):
Media session IP: Media IP from SIP trunk provider
Received from: Signalling IP from SIP trunk provder (as setup in trunk on 3CX)

Now calls work then after few hours audio is outbound only from phone system. Then after restart of services it works again.

These errors only appear on this system, we have re-checked firewall settings and they match all other working systems where this problem does not occur.

I have tried setting up the trunk again and still getting same problems.
 
Hello @benratty

Please run the firewall checker again and see if all ports pass the test. Also what version is the PBX running? You can see the exact build number on the Dashboard under the information column.
 
Professional 15.5.13103.5
 
Professional 15.5.13103.5
Thank you for the update. Let us know of the firewall test results once you are able to run it. Please note that running the check will cause the services to stop.
 
OK so I have run firewall checks for this site.

This is a physical PBX which is on Windows 10 which has been OK throughout the day despite those errors showing up in the logs highlighted above. The firewall check comes back OK going up to port 9255

resolving 'stun.3cx.com'... done
resolving 'stun2.3cx.com'... done
resolving 'stun3.3cx.com'... done
resolving 'sip-alg-detector.3cx.com'... done
testing 3CX SIP Server... done
stopping service... done
detecting SIP ALG... not detected
testing port 5060... done
starting service... done
testing 3CX Tunneling Proxy... done
stopping service... done
testing port 5090... done
starting service... done
testing 3CX Media Server... done
stopping service... done
testing ports [9000..9255]... done
testing port 9000... done
testing port 9001... done
testing port 9002... done
testing port 9003... done
testing port 9004... done
testing port 9005... done
testing port 9006... done

We tried migrating as state in previous post to migrate this to Debian release (on VMWare) and restore from the Windows backup. This all worked OK, call tests until this morning when for no reason we started to also see same errors as above and audio one way. So I have ran same firewall tests on the Debian version and got this (see below) and media ports on this version go to 10743. Is this why? As media ports open on firewall are only 9000-9500?

Both the old physical machine we want to retire and new virtual one are on same subnet and same network settings and same physical firewall.

resolving 'stun-eu.3cx.com'... done
resolving 'stun2.3cx.com'... done
resolving 'stun3.3cx.com'... done
resolving 'sip-alg-detector.3cx.com'... done
testing 3CX SIP Server... done
stopping service... done
detecting SIP ALG... not detected
testing port 5060... done
starting service... done
testing 3CX Tunneling Proxy... done
stopping service... done
testing port 5090... done
starting service... done
testing 3CX Media Server... failed (How to resolve?)
stopping service... done
testing ports [9000..10743]... failed (How to resolve?)
testing port 9000... done
testing port 9001... done
testing port 9002... done
testing port 9003... done
testing port 9004... done
testing port 9005... done
testing port 9006... done
 
Please note that SP5 uses more ports than the previous versions to accommodate larger installs and more shared parking slots. If this is a busy system the PBX could be trying to use ports that are not open on the firewall so you get one way audio. I would recommend opening the additional ports on the firewall and if this is a Debian installation also check the IP tables. See if this resolves the issue.
https://www.3cx.com/ports-used-3cx-phone-system-v14-v15/
 
Thanks Yiannish, I have opened he additional ports on firewall and run the firewall check again so this has resolved that and no errors on the firewall check now. I ran some test calls on it last night which all worked.

Just still concerned about this message that appears in activity log even after that, more because it doesn't appear in any of our other PBX's

T:Extn:EXTNO@[Dev:sip:[email protected]:5488;rinstance=1909b87ab6110656,Dev:sip:[email protected]:5060;rinstance=1-elm92gdgbpawasiwz6gvvlm1b5wbqz28;inst="0639386f"] from L:884.1[Line:10001<<PHONENUMBER] failed, cause: Cause: 408 Request Timeout/INVITE from 127.0.0.1:5488
06/08/2018 13:25:10 - NAT/ALG check:L:884.1[Line:10001<<PHONENUMBER] REQUEST 'INVITE' - some of SIP/SDP headers may contain inconsistent information or modified by intermediate hop

Media session IP ('c=' attribute) is not equal to the IP specified in contact header:
Media session IP:Media IP from SIP trunk provider
Contact IP:Signalling IP from SIP trunk provder (as setup in trunk on 3CX)
Media session IP ('c=' attribute) is not equal to the SIP packet source(IP Port):
Media session IP: Media IP from SIP trunk provider
Received from: Signalling IP from SIP trunk provder (as setup in trunk on 3CX)
 
Please note that SP5 uses more ports than the previous versions to accommodate larger installs and more shared parking slots. If this is a busy system the PBX could be trying to use ports that are not open on the firewall so you get one way audio. I would recommend opening the additional ports on the firewall and if this is a Debian installation also check the IP tables. See if this resolves the issue.
https://www.3cx.com/ports-used-3cx-phone-system-v14-v15/

I just got some logs back from trunk provider (Gamma), they are saying that the P-Asserted Identity is coming back with their SBC IP Address and not our external IP.

So the From address has Gamma's trunk signalling IP and not our external IP.

I have checked the SIP trunk setup and its the same as all the other PBX's with the P-Asserted Identity Host Part set to "GWHostPort". Is this correct?

If I change any of these SIP trunk settings does it require a restart of any services?
 
The error suggests that the IP in the SDP part of the invite does not match the IP of the contact header which is not necessarily wrong as the provider can request media to be sent to a different IP address.

I just got some logs back from trunk provider (Gamma), they are saying that the P-Asserted Identity is coming back with their SBC IP Address and not our external IP.
Make sure that you are using the template included in the PBX and you should have no issues. Gamma requires the VIA header to be set to your public IP so if that is set correctly then nothing else needs adjusting.
I have checked the SIP trunk setup and its the same as all the other PBX's with the P-Asserted Identity Host Part set to "GWHostPort". Is this correct?
Yes that is correct. Since it is working from other sites i do no think Gamma has an issue with the specific site.
 
The error suggests that the IP in the SDP part of the invite does not match the IP of the contact header which is not necessarily wrong as the provider can request media to be sent to a different IP address.


Make sure that you are using the template included in the PBX and you should have no issues. Gamma requires the VIA header to be set to your public IP so if that is set correctly then nothing else needs adjusting.

Yes that is correct. Since it is working from other sites i do no think Gamma has an issue with the specific site.

Yes the media and signalling IP addresses are different from Gamma.

We have used the standard template in 3CX system and the SIP VIA Header is set to our public IP.
 
We have used the standard template in 3CX system and the SIP VIA Header is set to our public IP.
Then you should be good to go as far as configuration is concerned. Let us know if you face any more issues now that the ports are open
 
Then you should be good to go as far as configuration is concerned. Let us know if you face any more issues now that the ports are open

Thanks. Just one more quick question, are there any known issues or requirements for virtualising the PBX, the Debian release we want to go live with is a VM in VMWare 6.5?, Single NIC, single CPU 8Gb RAM allocated.
 
Then you should be good to go as far as configuration is concerned. Let us know if you face any more issues now that the ports are open

Sorry Yiannis just one last difference I noticed, don't know if this is relevant.

Although we are not using STUN I have noticed in the parameters of the 3 PBX's where this entry in the log does not appear has the following set STUN_RESOLVED_PUBLIC_IP set to the external IP of the system. The PBX where this issue is does not have this option available in the parameters.

Thanks in advance.
 
Sorry Yiannis just one last difference I noticed, don't know if this is relevant.

Although we are not using STUN I have noticed in the parameters of the 3 PBX's where this entry in the log does not appear has the following set STUN_RESOLVED_PUBLIC_IP set to the external IP of the system. The PBX where this issue is does not have this option available in the parameters.

Thanks in advance.
See attached screenshots of working system and problem system when searching for the external IP in parameters. The problem system has this parameter missing.
 

Attachments

  • IsleofWIghtPBX.JPG
    IsleofWIghtPBX.JPG
    63.2 KB · Views: 33
  • OxfordPBX.JPG
    OxfordPBX.JPG
    66.9 KB · Views: 33
Thanks. Just one more quick question, are there any known issues or requirements for virtualising the PBX, the Debian release we want to go live with is a VM in VMWare 6.5?, Single NIC, single CPU 8Gb RAM allocated.
Please find the supported platforms in the link below:
https://www.3cx.com/docs/manual/installing-debian-linux-pbx/#h.5hoy5wwhhk5c

Just make sure you meet the minimum system requirements for your setup.
https://www.3cx.com/docs/recommended-hardware-specifications-for-3cx/
 
Although we are not using STUN I have noticed in the parameters of the 3 PBX's where this entry in the log does not appear has the following set STUN_RESOLVED_PUBLIC_IP set to the external IP of the system. The PBX where this issue is does not have this option available in the parameters.
If i am not mistaken this parameter is generated if the PBX switches to Dynamic Public IP even once and it uses STUN to lookup the public IP. If the PBX was installed using a static IP and this was never changed the parameter will not be there.
 
Status
Not open for further replies.

Forum statistics

Threads
111,889
Messages
589,580
Members
164,755
Latest member
adrhoades