locked
Skype Call dropping after 30-39 seconds RRS feed

  • Question

  • Hi Team, 

    I am at a bit of a loss after trying everything i can think of with this issue. 

    Environment:

    - 1x 2015 Standard edition server (6.0.9319.534); 1x 2015 Edge server (6.0.9319.534); hybrid enabled
    - Users homed on-prem to make use of Enterprise voice
    - Hybrid enabled, no users migrated
    -NAT Enabled AV Edge service (203.x.x.x -> 172.x.x.x)

    Problem:

    - Users on mobile devices (iPhone, Android) connecting to a skype (VoIP) call, NOT PSTN, see the call disconnect on their device after 30-39 seconds of the call going on. While the call is connected two way audio works.
    - Users can reconnect but only stay connected for the time period mentioned above
    - Users on a full SFB client on a laptop connected to the open internet stay connected to the call

    Investigation to date:

    - CLS logging (AudioVideoConferencingIssue scenario) shows the call connect for ~30 seconds and then drop. no error is shown.
    - Fiddler shows nothing untoward, only the call connected for the period of time, no disconnection shown
    - Wireshark shows a few 'ICMP Destination unreachable (Port Unreachable)' packets on the external adapter at the time of the call disconnecting; 
      - The Source IP is my Phone's Public IP (4G) address
      - The Destination IP is the IP of the External Edge AV Service (172.x.x.x)
      - The ICMP port is shown as 26370
      - These packets are often seen earlier in the call but it stays connected
    - All firewall rules triple checked 
      - Even tried an 'any any' rule briefly on the external firewall to see if that was the issue, no help
    - Used the MS test connectivity webpage and tested for AV Edge, no issues reported.
    - Connecting to the call via 'call me at' system works fine

    Attempted fixes so far:

    - Set-CsTrunkConfiguration for RTCPActiveCalls and ETCPCallsOnHold to FALSE
    - Set-CsTrunkConfiguration for EnableSessionTimer to TRUE

    I must stress, this appears to only be affecting mobile devices using the SFB application connecting using a VOIP call. There have been very rare occasions where the call stayed connected after the 30-39 second mark but disconnected at the 1 minute mark. This issue has been going on at this company for many years they tell me and I want to fix it.

    The only other interesting packets, just before the call drops are to do with the STUN packets, they are interesting in the fact that the user entry reverses in the STUN packet on the binding request. Could this be the cause of the drop out?

    

    Thanks in advance

    Tuesday, March 26, 2019 8:03 PM

Answers

  • Thanks to the two posters, they pointed me in the right direction!

    Reverse Proxy!

    Looking at our reverse proxy (we use IIS and ARR). 

    I found this website: https://erwinbierens.com/how-to-configure-iis-arr-for-skype-for-business/

    About half way down under Proxy I found the instruction to set the pass through keep alive time
    The article said:

    Set “Time-out(seconds)” to 600 and click “Apply”
    This will prevent mobile users from disconnecting.

    Looking at our configuration it was set to 30 seconds, after changing it to 600 seconds we were able to connect a call for over 10 minutes (600 seconds). There must be something in the Skype client that sends a keep alive longer than the time out window default of 30 seconds. 

    Thanks for your help!

    • Marked as answer by MessagingCamel Thursday, March 28, 2019 10:40 PM
    Thursday, March 28, 2019 10:40 PM

All replies

  • Hi,

    Thanks for the detailed info.

    Would suggest you have a check of the Edge settings in topology. Please make sure you have enabled the IP and NAT enabled addresses correctly as the following:

    Also, I'm wondering when the issue occurs, from internal network or external?

    Have you checked the reverse proxy? Did you find any issues related with the certificate configuration of RP? Please kindly note that Reverse Proxy provides some Web service features. It's both Edge server and reverse proxy with components together that provide external access to mobile users.

    Kind regards,

    Calvin Liu


    Please remember to mark the reply as an answer if you find it is helpful. It will assist others who has similar issue. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Wednesday, March 27, 2019 9:46 AM
  • That is very strange.

    I can't see it being the EDGE settings in the topology if it works for remote laptop users.

    I would check the Reverse Proxy config though.

    You don't have custom mobility policies in use do you (Get-CSMobilityPolicy)?

    It's strange there's nothing in the logs. Where is the BYE coming from? The server or your phone??

    Regards

    Thursday, March 28, 2019 1:40 PM
  • I will check the Reverse proxy today and confirm it is configured correctly. It could be something to do with SSL, however what baffles me is that if it were SSL it would affect all devices. 

    The only other test I will run is from a non-domain joined device (home PC) and I will see if that stays connected, I suspect it will. 

    Only have the global mobility policy, everything looks ok. 

    Identity                                  : Global
    Description                               :
    EnableOutsideVoice                        : True
    EnableMobility                            : True
    EnableIPAudioVideo                        : True
    RequireWIFIForIPVideo                     : False
    AllowCustomerExperienceImprovementProgram : True
    RequireWiFiForSharing                     : False
    AllowSaveCallLogs                         : True
    AllowExchangeConnectivity                 : True
    AllowSaveIMHistory                        : True
    AllowSaveCredentials                      : True
    EncryptAppData                            : False
    AllowDeviceContactsSync                   : True
    EnablePushNotifications                   : True
    RequireIntune                             : False
    VoiceSettings                             : VoIPAlways

    Ill report back after i have confirmed the reverse proxy configs

    Thursday, March 28, 2019 7:41 PM
  • Thanks calvin, 

    I will check the reverse proxy today. 

    i think your screenshot has the addresses around the wrong way. 

    172.x.x.x is the private IP on the LAN in the DMZ
    203.x.x.x is the public routable IP address. 

    Regardless, these are set correctly;

    ipv4 - 172.x.x.x

    nat address - 203.x.x.x

    Thursday, March 28, 2019 7:42 PM
  • Thanks to the two posters, they pointed me in the right direction!

    Reverse Proxy!

    Looking at our reverse proxy (we use IIS and ARR). 

    I found this website: https://erwinbierens.com/how-to-configure-iis-arr-for-skype-for-business/

    About half way down under Proxy I found the instruction to set the pass through keep alive time
    The article said:

    Set “Time-out(seconds)” to 600 and click “Apply”
    This will prevent mobile users from disconnecting.

    Looking at our configuration it was set to 30 seconds, after changing it to 600 seconds we were able to connect a call for over 10 minutes (600 seconds). There must be something in the Skype client that sends a keep alive longer than the time out window default of 30 seconds. 

    Thanks for your help!

    • Marked as answer by MessagingCamel Thursday, March 28, 2019 10:40 PM
    Thursday, March 28, 2019 10:40 PM
  • Ahh, glad to hear the issue is resolved! :)

    Please feel free to let us know if anything else.

    Kind regards,

    Calvin Liu


    Please remember to mark the reply as an answer if you find it is helpful. It will assist others who has similar issue. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, March 29, 2019 1:42 AM