v14 Media Server Issues

Discussion in '3CX Phone System - General' started by rbc94, Sep 8, 2015.

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

    Joined:
    Apr 24, 2012
    Messages:
    40
    Likes Received:
    0
    We just upgraded to v14 over the weekend and now we are running into problems with the media server needing to be restarted once every hour or so. I get the following error in the activity log when the audio stops working and the media server needs to be restarted.

    08-Sep-2015 13:17:14.021 NAT/ALG check:L:100.1[Line:10009<<716432XXX] REQUEST 'INVITE' - some of SIP/SDP headers may contain inconsistent information or modified by intermediate hop
    SIP proxy detected:
    Via:SIP/2.0/UDP 66.23.129.253:5060;branch=z9hG4bK1f01.ef8ee9b699d0b9f2aa93b5ca6366e641.0
    Via:SIP/2.0/UDP 66.23.129.236:5060;received=10.153.1.17;branch=z9hG4bK1f01.56a40c92e078c6de4b23353b2caf65db.0
    Via:SIP/2.0/UDP 66.23.129.10:5060;received=10.153.3.101;branch=z9hG4bK1f01.e783853b5b834b78141663938644b84b.0
    Via:SIP/2.0/UDP 4.55.39.95:5060;branch=z9hG4bK02B3ef90acfc252de41
    Media session IP ('c=' attribute) is not equal to the SIP packet source(IP:port):
    Media session IP: 4.55.39.70
    Received from: 66.23.129.253

    When a call is good, I receive this message:

    08-Sep-2015 13:17:14.230 NAT/ALG check:L:100.2[Ivr] RESPONSE 200 on 'INVITE' - basic check passed. No information for extended checks

    We have Nexvortex as our provider at both of or branches and I have already spoken with their tech support. everything is setup correctly on the providers tab and in our firewalls. They tell me it seems that 3CX v14 is now doing some sort of ALG checks and according to Nexvortex different IP's should show for RTP.

    Does anyone have any thoughts on this? If I can't figure this out I'm going to uninstall v14 and go back to 12.5 after we close.

    Thanks
     
  2. pj3cx

    pj3cx Active Member

    Joined:
    Aug 1, 2013
    Messages:
    645
    Likes Received:
    1
    Hi there,
    I doubt this is the real issue, here what you copied is the SIP ALG check - however in case the media server of the provider is different from sip server the logs will show this IPs discrepancy, and in this case it can be ignored.
    Please open a support ticket (yourself or through your reseller) so that this can be investigated further.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. rbc94

    Joined:
    Apr 24, 2012
    Messages:
    40
    Likes Received:
    0
    Thank you for the info. However, I have already downgraded to v12.5 and we no longer have any issues. I couldn't continue on v14 and have to monitor the media server all day and constantly restart the service.
     
  4. ericosborn09

    Joined:
    Dec 3, 2015
    Messages:
    30
    Likes Received:
    0
    We are now having this same issue on v14. Did you happen to find out anything?

    Eric,

    The main thing here is that your systems is saying that your:

    Media session IP ('c=' attribute) is not equal to the SIP packet source(IP:port):

    They need to match or there will be a RCF drop in voice which will drop the call as it is looking for a response from one ip and it is being sent from another.

    Sorry for the delay on this, but hope this points you in the right direction.

    Randall

    ---------------
    Is your network configured to take advantage of the nexVortex N+1 architecture with multiple redundancies? Check here to be sure!
    https://support.nexvortex.com/support/i ... utilize-it


    Ticket Details
    ________________________________________
    Ticket ID: ZBF-250-45992
    Department: Technical Support
    Type: SIP Trunking
    Status: Customer Pending
    Priority: Medium

    Helpdesk: https://support.nexvortex.com/support/index.php?
     
  5. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    This is just a hunch, but the default RTP ports have been expanded from V12.5 to V14, specifically in V12.5 they were 9000-9099, while now in V14 they are 9000-9255 (for VoIP calls).

    If you only have 9000-9099 open on the firewall, if you upgrade to V14, for the first 50 calls you will have audio and for all next calls you will get one-way audio as the V14 will start listening on port 9099+ (increments by 2 for every next call). Restarting the Media Server resets this back to 9000.

    To check if this is the case I would initially run the Firewall Checker and let all checks run, especially those 9099+ to see if they come up as open. If they are closed, open them up on the firewall and check again.
     
  6. benratty

    Joined:
    May 23, 2011
    Messages:
    72
    Likes Received:
    0
    I get this problem as well when using Gamma Telecom, asked Gamma they didn't know why other their media and sip are different IP's.

    07-Jun-2016 21:31:58.581 NAT/ALG check:L:4.1[Line:10000<<*mymobilenumber*] 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:88.215.55.12
    Contact IP:88.215.55.11
    Media session IP ('c=' attribute) is not equal to the SIP packet source(IP:port):
    Media session IP: 88.215.55.12
    Received from: 88.215.55.11
     
  7. smawisire

    Joined:
    Mar 27, 2015
    Messages:
    3
    Likes Received:
    0
    I am also having the same problem does anyone have a clue - there is about 10 users and happens quite offen.

    08-Jun-2016 17:19:22.178 NAT/ALG check:L:4.2[Line:10001>>mynumber] RESPONSE 200 on 'INVITE' - some of SIP/SDP headers contain inconsistent information or modified by intermediate hop
    SIP proxy detected:
    Record-Route:<sip:41.221.1.210:5060;transport=udp;lr>
    'audio' media IP is not equal to the SIP packet source(IP:port):
    'audio' media IP:41.221.0.37
    Received from:10.211.39.164
     
  8. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    The message "some of SIP/SDP headers contain inconsistent information or modified by intermediate hop" has most likely got nothing to do with some calls not getting audio on some calls, it is just stating that most likely the Provider might have the Media Server on a different IP than the SIP Server.

    Run the firewall checker and let it check all ports and make sure they show up as open. IF they don't adjust the firewall accordingly.
    Don't forget to restart the 3CX services after running it though.
     
  9. smawisire

    Joined:
    Mar 27, 2015
    Messages:
    3
    Likes Received:
    0
    The firewall checker runs successfully - in my case have no audio all the calls that have that message have got no audio.
     
  10. smawisire

    Joined:
    Mar 27, 2015
    Messages:
    3
    Likes Received:
    0
    this part is ok it sometimes appear on some calls that have audio,[08-Jun-2016 17:19:22.178 NAT/ALG check:L:4.2[Line:10001>>mynumber] RESPONSE 200 on 'INVITE' - some of SIP/SDP headers contain inconsistent information or modified by intermediate hop
    SIP proxy detected:]

    this part here is the problematic one, aii that have this on them have no audio.

    [Record-Route:<sip:41.221.1.210:5060;transport=udp;lr>
    'audio' media IP is not equal to the SIP packet source(IP:port):
    'audio' media IP:41.221.0.37
    Received from:10.211.39.164]
     
  11. NickD_3CX

    NickD_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Jun 2, 2014
    Messages:
    1,283
    Likes Received:
    68
    OK, i see what you mean.

    In that case you may e having a NATing issue. When you get the following message, the PBX is receiving the audio from a different IP than what the Provider said it would be sent from in the SIP Header.

    Code:
    'audio' media IP:41.221.0.37
    Received from:10.211.39.164]
    I would recommend checking any SIP ALG features on the Firewall in front of the 3CX Server.
    You could also see this more clearly in a Wireshark capture of a call that had this issue.
     
Thread Status:
Not open for further replies.