locked
Inbound call problems after 2019 August update RRS feed

  • Question

  • Hello,

    After a recent update to our Enterprise pool, edgepool, and databases, for an on premise SfB 2015 system there are some very odd call problems. As long as users are signed in with any status other than "Offline", everything works normally.

    1) When a user, contact, or endpoint persence is "Offline" calls to their enterprise voice enabled account and DID are dropped by the SfB server as a 403 forbidden sent to our SBC.

    2) Above happens as well when a user signs into a mobile client or on the SfB client for a Mac even if their status is "Available". These mobile clients are still able to place calls in and out of our org.

    In either case the 403 Forbidden results in the telco carrier of the caller to get a message that the line is diconnected or not in service. The calls are also referenced through UC in exchange as a missed call. This is happening on both an inbound SIP trunk and a full PRI through Century Link.

    Digging into the problem with ClsLogger and Snooper expands on the 403 forbidden to include the reason of

    "ms-diagnostics: 13022;reason="The request from PSTN gateway could not be routed as it is restricted based on location";source="frontendx.xxx.xxx";appName="InboundRouting"

    We have three network sites and policies. Only one of them is setup to use location based routing.

    Really stumped here. The problem was not identified for about a week after the updates were finished. In this time we had to also replace several certificates that were expiring. So with multiple changes, it is hard to say where the problem lies. As far as I can tell, all of the certs are in place, trusted and valid for internal, edge, reverse proxy, and internal pools.

    I have the log files with sip and message traffic if anybody thinks it could help.

    Friday, May 8, 2020 10:08 PM

All replies

  • Hi tdavidson25!

    Do you have any operations before this issue occurred?

    Do you mean user cannot make PSTN call normally when their presence is unavailable?

    In order to make this issue more clearly, would you mind provide more detailed error logs about this issue?

    It recommends you check your voice policies to see if there are some settings that block this call to enterprise enabled account.

    To my knowledge, Location-Based routing provides the flexibility to scope these rules to specific regions, specific gateways or to specific set of users only. For ingress call, it can prevent incoming PSTN calls to ring Lync endpoints if the PSTN gateway routing the incoming call is not located in the same region as the called Lync user.

    Besides, you can try to run the command "Set-CsTrunkConfiguration -Identity:"Service:PSTNGateway:<trunk>" -EnableLocationRestriction:$False". By turning this feature off allows the user to receive calls to their DDI from the PSTN regardless of which site they are currently located.

    Best Regards,
    Jimmy Yang

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com
    Monday, May 11, 2020 7:18 AM
  • Hello Jimmy,

    Prior to the upgrade, the only known issues were regarding inbound calls to internal DID for Mac clients. All other operations were working correctly regardless of if they were on our internal network or connecting from remote networks over public IP addresses.

    The specific issue is related to two scenarios. First, if the user is signed out of all clients and their current status is "offline", any calls to that user from an external number through our PSTN or SIP trunk result in the call not connecting and returning the telco carriers recording for a disconnected number. The second scenario is if the user is signed on with a mobile client or a Mac client. In that case they will show available, but a call from an external number to that user ends with a telco recording for a disconnected number. There were no issues with the user placing calls or receiving calls from within our network.

    In effort to fix this issue I have removed the installed updates. I am now trying to resolve logon issues around mobility, for Mac and mobile device clients. 

    For logs, all I currently have is the output from clsLogger for inbound/outbound calls from my external number. Are there different logs that you recommend looking at for this failure? I will need to scrub internal information from those logs before I submit here.

    Monday, May 11, 2020 5:06 PM
  • Hi tdavidson25

    According to your description, can we understand your external PSTN number cannot call to these users: Offline users in SFB, mobility user, SFB for Mac client user, right?

    In this case, it seems a best way to check your PSTN configuration in Skype for Business Server:

    https://docs.microsoft.com/en-us/skypeforbusiness/plan-your-deployment/enterprise-voice-solution/pstn-connectivity-0?toc=/SkypeForBusiness/toc.json&bc=/SkypeForBusiness/breadcrumb/toc.json

    Considering your mobile user also have the issue, we also recommend you check per-user mobility  policy as these policies also manage a user's ability to employ Call via Work, a feature that enables users to make and receive phone calls on their mobile phone.

    https://docs.microsoft.com/en-us/skypeforbusiness/set-up-policies-in-your-organization/set-up-mobile-policies-for-your-organization#prevent-a-user-from-making-voice-over-ip-calls-using-a-mobile-device

    In addition, we also recommend that you share your error log information about this issue (Snooper and CLSLogger tool) to help us narrow down this issue. Please don't forget to cover your own personal information before sharing.

    Thanks for your understanding and patience!

    Best Regards,
    Jimmy Yang


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


    Thursday, May 14, 2020 9:15 AM
  • Hi,
    I am checking the status of this case. Please let us know if you would like further assistance.
    Meanwhile, if the reply is helpful to you, please try to mark it as an answer to close the thread, it will help others who encounter the same issue and read this thread.
    Thank you for your understanding and patience!

    Best Regards,
    Jimmy Yang


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


    Thursday, May 21, 2020 5:13 AM