none
Skype For Business replying with 401 unauthorized to my SBC. RRS feed

  • Question

  • I've got an odd one for you all, and I'm stumped.

    My SFB 2015 standard edition pool (latest CU), all requests from my SBC are getting a 401 Unauthorized back.  OPTIONS, INVITE, both receive the same response:

    20:42:47.056  ---- Incoming SIP Message from 10.21.12.27:5060 to SIPInterface #2 (SBC) TCP TO(#214) SocketID(14059) ----
    
    SIP/2.0 401 Unauthorized
    Date: Wed, 09 Oct 2019 03:42:46 GMT
    WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="bsafe1.biamp.com", version=4
    WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/bsafe1.biamp.com", version=4
    WWW-Authenticate: TLS-DSK realm="SIP Communications Service", targetname="bsafe1.biamp.com", version=4, sts-uri="https://bsafe1.biamp.com:443/CertProv/CertProvisioningService.svc"
    From: <sip:10.21.12.18>;tag=1c987750742
    To: <sip:10.21.12.18>;tag=64F7174925BF1C6464425619EA029162
    Call-ID: 2108565132242018144243@10.21.12.18
    CSeq: 1 OPTIONS
    Via: SIP/2.0/TCP 10.21.12.18:5060;alias;branch=z9hG4bKac1047332157;ms-received-port=60062;ms-received-cid=26F700
    Server: RTC/6.0
    Content-Length: 0
    
    

    I've tried removing the SBC from the topology, re-adding it and got the same result.

    I have another SBC (in a different location) that works just fine for OPTIONS and INVITE messages

    20:42:38.169  ---- Incoming SIP Message from 172.16.5.93:5060 to SIPInterface #2 (SBC) TCP TO(#257) SocketID(3) ---- 
    
    SIP/2.0 200 OK
    FROM: <sip:10.21.12.18>;tag=1c1756124366
    TO: <sip:10.21.12.18>;tag=ffbe9fe64c
    CSEQ: 1 OPTIONS
    CALL-ID: 1613776503242018144233@10.21.12.18
    VIA: SIP/2.0/TCP 10.21.12.18:5060;branch=z9hG4bKac2007490137;alias
    ACCEPT: application/sdp
    CONTENT-LENGTH: 0
    ACCEPT-ENCODING: gzip
    ACCEPT-LANGUAGE: en
    ALLOW: NOTIFY
    ALLOW: BENOTIFY
    SERVER: RTCC/6.0.0.0 MediationServer
    

    I'm open to suggestions, I'm at a loss.

    Wednesday, October 9, 2019 4:22 AM

All replies

  • Hi Ron Prague,

    Because of the limitation of our forum, we are not familiar with SBC configuration.

    In my research, there is a document related to this case for your reference:https://social.technet.microsoft.com/Forums/lync/en-US/721afdb2-8edd-4bf6-92af-0fffdb74169f/cannot-authorise-sip-trunk-with-register-message-via-sonus-sbc?forum=sfbfr


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Wednesday, October 9, 2019 6:42 AM
    Moderator
  • Hi,

    Please consider Sharon's link but also it looks like the Options message is using Port 5060 so please confirm you have Port 5060 configured in the topology and SBC. It's also been allowed through your firewall.

    The SfB Server receives OPTIONS message from the SBC and likewise sends OPTIONS messages to the SBC.

    Please ensure you also have the SBC HostName in your internal DNS and it matches the FQDN specified in your topology.

    Wednesday, October 9, 2019 2:03 PM
  • Hi Ron Prague,

    Because of the limitation of our forum, we are not familiar with SBC configuration.

    In my research, there is a document related to this case for your reference:https://social.technet.microsoft.com/Forums/lync/en-US/721afdb2-8edd-4bf6-92af-0fffdb74169f/cannot-authorise-sip-trunk-with-register-message-via-sonus-sbc?forum=sfbfr


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thank you Sharon, the SBC registers it's SIP trunk just fine.  It's the OPTIONS message it's sending to SFB that's being bounced.

    There are two SBCs, one SFB responds fine to, the second SFB is sending back 401 unauthorized.

    What I need to know is, is there any reason why SFB would respond with 401 unauthorized from that SBC?  The port is open (port 5060), TCP is the transport chosen, there's no Firewall in place, the internal DNS name matches the FQDN in my topology.

    Wednesday, October 9, 2019 2:20 PM
  • Hi,

    Please consider Sharon's link but also it looks like the Options message is using Port 5060 so please confirm you have Port 5060 configured in the topology and SBC. It's also been allowed through your firewall.

    The SfB Server receives OPTIONS message from the SBC and likewise sends OPTIONS messages to the SBC.

    Please ensure you also have the SBC HostName in your internal DNS and it matches the FQDN specified in your topology.

    Double checked all of those things just to be sure.  The port is open, hostname is in DNS, FQDN matches the topology builder.

    This SFB deployment worked fine for years.  We migrated users to Teams 2 months ago and hadn't looked at it in a while.  I had to migrate some users back and found this error last week.

    Wednesday, October 9, 2019 2:22 PM
  • I'm sure you've done it but have you tried to restart the Mediation service on the Front End?

    Also have a look at csclslogging as you might get more information from that?

    Is your original screenshot from the SBC logging?

    Wednesday, October 9, 2019 3:02 PM
  • Hi Ron Prague,

    According to your description, you move users from Microsoft Teams to Skype for Business.

    Do you try the same user account in the two SBC?

    There is a document about move users for your reference:

    https://docs.microsoft.com/en-us/powershell/module/skype/move-csuser?view=skype-ps


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Monday, October 14, 2019 9:52 AM
    Moderator
  • Hi Ron Prague,

    Is there any update on this case?

    Please feel free to drop us a note if there is any update.

    Have a nice day!


    Best Regards,
    Sharon Zhao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Friday, October 18, 2019 2:39 AM
    Moderator