locked
Skype for Business Standard Server with TCP Sip trunk AND TLS Sip Trunk - possible? RRS feed

  • Question

  • Hi,

    anyone knows if it is possible to have two separate sip providers running on the collocated media IP-Address of a Standard Frontend Server!? Currently i have one provider working with tcp and one working with tls - the latter seems not able to connect while the tcp trunk is working fine. 

    Also there is 5067 not open althouh it is configured published and enabled in topology builder but i can see port 5068 is open 3 times...

    Thanks in advance!

    Monday, April 11, 2016 1:08 PM

Answers

  • Hi,

    thanks for you effort i think we sorted it out... - morale of story:

    While the working carrier establishes open TCP sessions outbound and the Inbound calls are rolling in over this connection as well, the second carrier does a separate tcp connection for each incoming call - but this was not open in our firewall and so never even reached the Mediation Server.

    The next mistake was to look at the tcp connections in ressource Monitor but i should have had a look on the monitored ports in ressource Monitor...

    Best regards and thanks for your effort

    Oliver

    • Proposed as answer by Ben Donaldson Wednesday, April 13, 2016 8:18 AM
    • Marked as answer by Eason Huang Thursday, April 28, 2016 8:07 AM
    Wednesday, April 13, 2016 8:08 AM

All replies

  • Oliver,

    This should work without issue. If you haven't already, you may need to restart the Mediation service on the pool where the SIP Trunks are terminating.

    Aside from that - if you're using the Global Trunk Configuration, make sure that SRTPMode is set to "Optional". This will enable connections over TCP and TLS. However, if the providers have different requirements for the SIP Trunks, it may be a good idea to setup a Trunk Configuration per provider. If you do, it would be recommended to set the SRTPMode for the TLS trunk as "Required". I've included the TechNet article for the New-CsTrunkConfiguration cmdlet below:

    https://technet.microsoft.com/en-us/library/gg413021.aspx

    Monday, April 11, 2016 5:56 PM
  • Hi Oliver/Phil, 

    Just found something in the below article. Feel free to correct, if I had misunderstood the requirement. 

    https://technet.microsoft.com/en-us/library/gg398619.aspx

    As shown in the diagram, an IP virtual private network (VPN) is used for connectivity between the enterprise network and the public switched telephone network (PSTN) service provider. The purpose of this private network is to provide IP connectivity, enhance security, and (optionally) obtain Quality of Service (QoS) guarantees. Because of the nature of a VPN, you do not need to use Transport Layer Security (TLS) for SIP signaling traffic or secure real-time transport protocol (SRTP) for the media traffic. Connections between the enterprise and the service provider therefore consist of plain TCP connections for SIP and plain real-time transport protocol (RTP) (over UDP) for media tunneled through an IP VPN. Ensure that all firewalls between the VPN routers have ports open to allow the VPN routers to communicate, and that the IP addresses on the external edges of the VPN routers are publicly routable.

    SIP Trunking Topology


    Thanks,
    Anoop Karikikuzhiyil Babu | Erstwhile Microsoft Premier Unified Communication Engineer. My blog
    ________________________________________________________________
    Please mark the reply as an answer if you find it is helpful :-)
    ________________________________________________________________


    Tuesday, April 12, 2016 5:32 AM
  • Hi,

    thanks for your hint but that is already configured.:

    Identity                                  : Global
    OutboundTranslationRulesList              : {}
    SipResponseCodeTranslationRulesList       : {}
    OutboundCallingNumberTranslationRulesList : {}
    PstnUsages                                : {XXXXX}
    Description                               :
    ConcentratedTopology                      : True
    EnableBypass                              : True
    EnableMobileTrunkSupport                  : False
    EnableReferSupport                        : False
    EnableSessionTimer                        : False
    EnableSignalBoost                         : False
    MaxEarlyDialogs                           : 2
    RemovePlusFromUri                         : False
    RTCPActiveCalls                           : False
    RTCPCallsOnHold                           : False
    SRTPMode                                  : NotSupported
    EnablePIDFLOSupport                       : False
    EnableRTPLatching                         : False
    EnableOnlineVoice                         : False
    ForwardCallHistory                        : False
    Enable3pccRefer                           : False
    ForwardPAI                                : False
    EnableFastFailoverTimer                   : True
    EnableLocationRestriction                 : False
    NetworkSiteID                             :

    Identity                                  : Service:PstnGateway:XXXXXXX

    OutboundTranslationRulesList              : {}
    SipResponseCodeTranslationRulesList       : {}
    OutboundCallingNumberTranslationRulesList : {}
    PstnUsages                                : {Xxxxxx}
    Description                               : Toplink-Test
    ConcentratedTopology                      : True
    EnableBypass                              : False
    EnableMobileTrunkSupport                  : False
    EnableReferSupport                        : False
    EnableSessionTimer                        : False
    EnableSignalBoost                         : False
    MaxEarlyDialogs                           : 20
    RemovePlusFromUri                         : False
    RTCPActiveCalls                           : True
    RTCPCallsOnHold                           : True
    SRTPMode                                  : Optional
    EnablePIDFLOSupport                       : False
    EnableRTPLatching                         : False
    EnableOnlineVoice                         : False
    ForwardCallHistory                        : False
    Enable3pccRefer                           : False
    ForwardPAI                                : False
    EnableFastFailoverTimer                   : False
    EnableLocationRestriction                 : False
    NetworkSiteID                             :

    However Port 5067 appears not to be open although i did publish the topology and "enabled-cscomputer" - even restarted the whole machine 2 or 3 times now...

    Tuesday, April 12, 2016 2:07 PM
  • Hi Anoop,

    thanks for your hint but i have in fact something different in mind, i have 3 Trunks of 2 different sip providers working - however only the 2 Trunks with the carrier using tcp are working an i can only see port 5068 open in ressource Monitor although configured differently...

    I attached a screenshot to simplify what i mean

    Tuesday, April 12, 2016 2:21 PM
  • Hi Oliver,

    May be you can try collecting a wireshark on the mediation server and filter with both port number 5067 & 5068 to understand what is really happening.


    Thanks,
    Anoop Karikikuzhiyil Babu | Erstwhile Microsoft Premier Unified Communication Engineer. My blog
    ________________________________________________________________
    Please mark the reply as an answer if you find it is helpful :-)
    ________________________________________________________________

    Tuesday, April 12, 2016 7:03 PM
  • That's odd. The mediation server should start listening on your TLS port as soon as its configured and published, regardless of the rest of the configuration - you don't even need to define gateways or trunks.

    For example, I've just set my mediation server to TCP 7777 and TLS 9999 and published it without any trunks or gateways, and can see both these ports listening on said server.

    Have you tried changing the port to something other than 5067 for the sake of it?

    Is this a single standard edition with collocated mediation role?

    Kind regards
    Ben


    Note: If you find a post informative, please mark it so using the arrow to the left. If it answers a question you've asked, please mark the thread as answered to aid others when they're looking for solutions to similar problems.


    Tuesday, April 12, 2016 7:35 PM
  • Hi Ben- this is a std server with mediation collocated. 

    Oliver -as Ben suggested try with a different port.

    Note: With multiple trunk support in Skype for Business Server, you can define multiple SIP signaling ports on the Mediation Server for communication with multiple PSTN gateways. When defining a trunk, the Associated Mediation Server port must be within the range of the listening ports for the respective protocol allowed by the Mediation Server. This port range is defined under Skype for Business Server and Mediation Pools. Right-click the Mediation Server pool of interest, and select Edit Properties. Specify the port range in the Listening ports field.


    Thanks,
    Anoop Karikikuzhiyil Babu | Erstwhile Microsoft Premier Unified Communication Engineer. My blog
    ________________________________________________________________
    Please mark the reply as an answer if you find it is helpful :-)
    ________________________________________________________________

    Tuesday, April 12, 2016 7:43 PM
  • Hi,

    thanks for you effort i think we sorted it out... - morale of story:

    While the working carrier establishes open TCP sessions outbound and the Inbound calls are rolling in over this connection as well, the second carrier does a separate tcp connection for each incoming call - but this was not open in our firewall and so never even reached the Mediation Server.

    The next mistake was to look at the tcp connections in ressource Monitor but i should have had a look on the monitored ports in ressource Monitor...

    Best regards and thanks for your effort

    Oliver

    • Proposed as answer by Ben Donaldson Wednesday, April 13, 2016 8:18 AM
    • Marked as answer by Eason Huang Thursday, April 28, 2016 8:07 AM
    Wednesday, April 13, 2016 8:08 AM
  • Ah glad it's sorted. I always use NetStat from a cmd line to query my ports so didn't even think about how you were querying the listening ports. Firewall... just like 99% of call flow issues in Lync / Skype ;)


    Note: If you find a post informative, please mark it so using the arrow to the left. If it answers a question you've asked, please mark the thread as answered to aid others when they're looking for solutions to similar problems.

    Wednesday, April 13, 2016 8:18 AM