Troubleshooting NAT

Discussion in '3CX Phone System - General' started by craigreilly, Jun 25, 2013.

Thread Status:
Not open for further replies.
  1. craigreilly

    craigreilly Well-Known Member

    Joined:
    Feb 1, 2012
    Messages:
    3,321
    Likes Received:
    252
    Is this something to worry about?
    Code:
    NAT/ALG check:L:33.1[Line:10000<<+1602xxx0071] REQUEST 'INVITE' - some of SIP/SDP headers may contain inconsistent information or modified by intermediate hop SIP proxy detected:
    
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. ian.watts

    ian.watts Active Member

    Joined:
    Apr 8, 2011
    Messages:
    532
    Likes Received:
    1
    Other than a heel.. I see that at times.. seems to happen at times with trunks. They mostly all connect to upstream/higher tier providers for their VoIP traffic.. so all that handoff between SIP and then the RTP getting transcoded at times and routed at other times.. seems to happen from time to time that I see.

    I suppose their's SRTP and SIPS for the paranoid. ;)
     
  3. craigreilly

    craigreilly Well-Known Member

    Joined:
    Feb 1, 2012
    Messages:
    3,321
    Likes Received:
    252
    so, it sounds like no big deal...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. markshehan

    markshehan New Member

    Joined:
    Nov 14, 2012
    Messages:
    141
    Likes Received:
    0
    I just wanted to explain what 3cx is looking at and reporting here. It isnt the RTP information. That is a given that this will be different as none of us put our soft switches in our PSTN data centers.

    3cx is looking at the HOST addresses, specifically the INVITE, FROM, CONTACT (and if used REMOTE PARTY AND P-ASSERTED ID) and is trying to ensure that it is not spoofed so checks that they match the IP that sent the invite. This would indicate someone is possibly spoofing or they could potentially be a firewall/nat mis match and the audio or responses may not go through.

    In our case we use DNS SRV records for our sip trunks and have multiple soft switches in multiple data centers all replicating real time. This ensures extremely high availability automatically. So all our header HOSTs have our DNS SRV FQDN information (depending on which main data center it came from). So they will never match the IP we send from as it changes each call depending on the actually soft switch processing this call.

    In theory 3cx could do a lookup of this host and check if it matches, but the cost of another lookup outweighs the gains.

    So if you have any issues sending responses back then this could be an area to investigate, but if your calls are all going through (which they do in 99% of these cases) then it is just a situation such as ours and is no problem.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. craigreilly

    craigreilly Well-Known Member

    Joined:
    Feb 1, 2012
    Messages:
    3,321
    Likes Received:
    252
    Thanks for the thorough explanation.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.