Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

Please Fix broken implementation of SRV record handling

Discussion in 'Ideas' started by Elliott, Oct 12, 2017.

Please Fix broken implementation of SRV record handling 5 5 32votes
5/5, 32 votes

  1. Elliott

    Joined:
    Oct 11, 2017
    Messages:
    5
    Likes Received:
    6
    So I logged a support case with 3CX about this and was told it was expected behavior and I needed to submit a feature request... This was originally a request to support SIP OPTIONS for monitoring SIP server health, but actually just supporting SRV record lookups as per the SIP RFC would be a start.

    So here goes:

    3CX does not support SRV records properly.

    From RFC3263: Session Initiation Protocol (SIP): Locating SIP Servers

    4.3:
    For SIP requests, failure occurs if the transaction layer reports a 503 error response or a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP)... If a failure occurs, the client SHOULD create a new request, which is identical to the previous.... That request is sent to the next element in the list as specified by RFC 2782 [The next SRV record]

    Instead, 3CX does the following:
    It looks up the SRV record, attempts with the highest priority record, but if a failure occurs (or this server is down) 3CX fails the call. Subsequent calls will continue to use the non-working SIP Server from the SRV record randomly, even if there are other servers with lower priority (backups).

    This makes implementing redundant SBC's/SIP Servers a manual process of adding the trunk multiple times. We have (had) a planned rollout of hudreds of 3CX instances and the inability of 3CX to support DNS fail-over, a pretty essential part of the SIP protocol design, basically makes this a deal breaker.

    And a warning to anyone using SRV records for 3CX: If you have an SBC/SIP server failure, your calls WILL NOT work reliably outbound until this basic functionality is fixed.
     
  2. accentlogic

    accentlogic New Member

    Joined:
    Nov 14, 2013
    Messages:
    181
    Likes Received:
    77
    This has been confirmed to us by a 3CX certified SIP provider. I love the concept, it just needs to work reliably and would simplify many installations or make them more robust. Feel free to PM me for details.
     
  3. Sopock

    Sopock Member

    Joined:
    Jul 11, 2012
    Messages:
    447
    Likes Received:
    20
    That could also help in this scenario instead of relying on TTL values and updating the IP of same FQDN?
    https://www.3cx.com/community/threads/failover-on-enterprise.51324/
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. Elliott

    Joined:
    Oct 11, 2017
    Messages:
    5
    Likes Received:
    6
    Bump :)

    Sorry Sopock, for us manual DNS intervention is not a replacement for SRV (which works flawlessly when implemented as per the RFC, which 3CX has not followed)

    Really wanting you guys to implement this so we can roll this out to dozens of customers...
     
  5. cobaltit

    cobaltit Well-Known Member

    Joined:
    Mar 22, 2012
    Messages:
    1,609
    Likes Received:
    243
    BUMP

    Running into this concern now as well. Did you make a feature request already?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. cobaltit

    cobaltit Well-Known Member

    Joined:
    Mar 22, 2012
    Messages:
    1,609
    Likes Received:
    243
    Ignore the feature request part, I just realized this post was in the ideas section
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. cobaltit

    cobaltit Well-Known Member

    Joined:
    Mar 22, 2012
    Messages:
    1,609
    Likes Received:
    243
    @Elliott

    Have you tested this since the SP2 release? I don't see anything in the notes about it but hoping it is working.

    Also, per this post 3CX has joined the SIP Forum as a full member and is going to take the SIPconnect certification test. Unless I'm reading it wrong, supporting SRV records per the RFC is a requirement to be SIPconnect v1.1 certified so hopefully they are working on it and it's not considered a feature request so much as a requirement.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. Elliott

    Joined:
    Oct 11, 2017
    Messages:
    5
    Likes Received:
    6

    Hey,

    So I haven't tried it specifically but I did go through the release notes and there is nothing about it in there.

    It became a huge issue with us and we ended up having to redesign our SBC deployment to fit this problem.

    3CX came back to me and said it's a feature request rather than a bug, which makes zero sense for a supposed "standards based" PBX, so lets hope the SIPConnect thing makes them pick up their game!
     
  9. Miggidy

    Joined:
    Jan 29, 2018
    Messages:
    4
    Likes Received:
    3
    Has this bug/feature been fixed/implemented yet?

    It's pretty poor form this is even considered a feature request by a serious software provider.
     
    josea and DrewHammond like this.
  10. bbaker73

    bbaker73 New Member

    Joined:
    Nov 27, 2015
    Messages:
    143
    Likes Received:
    26
    Guys, is this the same issue I experienced with a voip provider a few times the last few days? They have gw.sipprovider.com, gw1.sipprovider.com, gw2.sipprovider.com. Our trunks are registered with gw. and provider says they have SRV record. They had an outage and all of our trunks for all of our clients went down for 10+ minutes. Along with emails for trunks not registed, 3CX servers also sent:

    Registration at SIPTRUNK has failed.
    Destination (sip:12345678@gw.sipprovider.com:5060) is not reachable, DNS error resolving FQDN, or service is not available.

    Sip provider says only 3CX customers had issues during the problem as gw2. was up and processing calls the whole time. Based on this, their recommendation is to dual register gw1 and gw2 trunks with them and instead of using gw. Seems this is a workaround and a LOT of added work to put multiple trunks for each of our clients (each with 2-10 trunks now) and modify multiple outbound rules with backup route as well.
     
    Miggidy likes this.
  11. Miggidy

    Joined:
    Jan 29, 2018
    Messages:
    4
    Likes Received:
    3
    Yep, same issue. 3CX need to fix SVR or they are going to start losing customers. We are certainly looking at alternative options already.
     
  12. josea

    Joined:
    Sep 13, 2017
    Messages:
    23
    Likes Received:
    6
    We were also affected and got the same recommendation. Which is okay coming from the trunk provider but it is a waste of time. This should be fixed in the 3CX software...
     
    Miggidy likes this.
  13. bbaker73

    bbaker73 New Member

    Joined:
    Nov 27, 2015
    Messages:
    143
    Likes Received:
    26
    Maybe you guys can answer this without a lot of testing on my end. If I do set up a backup trunk with provider, do I specify the same DID's on both trunks, and since DID's are specified per trunk and inbound rules in 3CX, do I have to create a 2nd duplicate set of inbound DID's rules for the new trunk to match the other trunk, in essence having two sets of rules for the same DID? Seems like I remember when switching voip providers some time ago, we did create a duplicate inbound rule set, but found 3CX matched the first rule for the DID regardless of the trunk it came in on.
     
  14. bbaker73

    bbaker73 New Member

    Joined:
    Nov 27, 2015
    Messages:
    143
    Likes Received:
    26
    I'm finding in testing adding 2nd backup trunk to provider, that I DO have to set up duplicate inbound rules/DID for each trunk for calls to route. :( Even with import/export of Inbound rules and modifying it in bulk to add the rules for the 2nd truck, it's still too much work. I have clients with hundreds of DID/Inbound rules. There has to be a simpler way to work with multiple trunks from the voip provider.
     
  15. 3CXDude

    3CXDude New Member

    Joined:
    Oct 1, 2015
    Messages:
    110
    Likes Received:
    30
    Its a very poor show from 3CX on this in my opinion.

    Given the fact that this thread has been ongoing for 6 months and there has not even been a response, says it all really.
     
  16. cobaltit

    cobaltit Well-Known Member

    Joined:
    Mar 22, 2012
    Messages:
    1,609
    Likes Received:
    243
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  17. TP_

    TP_

    Joined:
    May 15, 2018
    Messages:
    47
    Likes Received:
    4
  18. Miggidy

    Joined:
    Jan 29, 2018
    Messages:
    4
    Likes Received:
    3
    +1
     
    DSXDATA likes this.
  19. Elliott

    Joined:
    Oct 11, 2017
    Messages:
    5
    Likes Received:
    6
    Can anyone report if this is fixed with 15.5.12663.5?

    I notice in the latest changelog:
    "Improved Call Manager failover to next server based on SRV Record."

    Would appreciate someone from 3CX explaining this change in some more detail?
     
    bbaker73 and accentlogic like this.
  20. Nico-belcenter

    Joined:
    Aug 20, 2018
    Messages:
    8
    Likes Received:
    1
    Any updates on this ?
    Our customer has the same issue