locked
Call Admission Control Failures - How to determine exactly which bandwidth policy is causing failure? RRS feed

  • Question

  • Hi,

    I am trying to troubleshoot an issue where a remote Lync user is unable to join a Lync conference hosted on the internal lync pool because of Call Admission Control.

    When tries to initiate a conference, gets the 'the network is busy, cannot join the meeting' message.  If Call Admission Control is turned off in Lync, then the Meet Now conference initiation works.

    Regarding Call Admission control setup -  There is a Central site which contains the Lync pool, Edge server, and local subnets with no bandwidth policy applied. Then there are other sites defined which are the remote corporate sites joined by WAN which do have bandwidth policies applied.

    I am trying to figure out why this particular remote call is being dropped.  I want to know which bandwidth policy is being applied that is causing the drop - well really I just want to know why the call is being dropped - but zeroing in on the bandwidth policy seemed like a good place to start.    But I can't find anything in the logs which says which bandwidth policy is being applied.

    Here is what is shown in Monitoring server reports regarding the call.  I have replaced server names and IPs with description (within <>).

    From user agent: UCCAPI/4.0.7577.4053 OC/4.0.7577.4061 (Microsoft Lync 2010)   
      Diagnostic header: 5; source="<Front-End servername.domain.com"; reason="Insufficient bandwidth to establish session. Attempt PSTN re-route"; component="Audio Video Conferencing Server"; CalleeMediaDebugaudio="audio:ICEWarn=0x48000,LocalSite=<IP address of internal pool>:53762,LocalMR=<Internal facing IP of Edge server>,RemoteSite=<Public IP of the router of the remote user>:20031,RemoteMR=<Lync AV Edge external IP> address>:59318,PortRange=49152:57500,RemoteMRTCPPort=59318,LocalLocation=2,RemoteLocation 

    Here is what is shown in the \\<Lync file share>\1-ApplicationServer-1\AppServerFiles\PDP\ BwCheckFailure csv log.

    Time,Call-ID,Modality(A:Audio;V:Video),Req BwMin,Req BwMax,Local IP,Remote IP,Local Relay,Remote Relay,Relay Failure Code(L:Local Relay; R:Remote Relay; A: All),AlternatePath,Failed Links(IS:Inter-Site Link; R:Inter-Region Link; S:Site to Region Link),Link Capacity,Link Utilization,Self Location(0:Unknown;1:Internet;2:Intranet),Peer Location(0:Unknown;1:Internet;2:Intranet), Federation(0:No;1:Enterprise;2:Public Cloud)

    2012-04-22T10:56:59,0fb4c5a2ca3149cfbd37ed3e1e3dfae4,A,40,200,<Lync Front End server IP>,<private NATed IP of remote user>,<Lync AV Edge IP>,<Lync AV Edge IP>,A,F,,,,2,1,0
    2012-04-22T10:56:59,0fb4c5a2ca3149cfbd37ed3e1e3dfae4,A,40,200,<Lync Front End server IP>,<private NATed IP of remote user>,<Lync AV Edge IP>,<Lync AV Edge IP>,A,F,,,,2,1,0

    I notice in the Failed Links column from the CSV data above there is no failed Link specified.  Is this a clue maybe?

    So I still don't know from the logs which bandwidth policy in particular was applied, and hence why the call was dropped.   How can I find this information?  Or is there another way to approach this?

    Any help greatly appreciated.



    • Edited by SL32 Saturday, April 21, 2012 11:49 PM
    Saturday, April 21, 2012 11:47 PM

Answers

  • Found simple resolution.

    I didn't have Enable Audio Alternate Path and Enable Video Alternate path ticked in the Region settings.   I thought these settings only applied to calls that were not able to be completed across WAN site links due to bandwidth polices (i.e. thought you would enable the settings if your remote site had a PSTN gateway or Edge server and could use these for calls if the WAN link was congested).  However it also turns out that if not enabled will result in the scenario I describe above.

    Thanks



    • Marked as answer by SL32 Tuesday, April 24, 2012 8:46 PM
    • Edited by SL32 Tuesday, April 24, 2012 8:50 PM
    Tuesday, April 24, 2012 8:46 PM

All replies

  • Hi,

    I can highly recommend the reskit tool "Bandwith policy Service Monitor". It is a tool I have used to figure out similar issues you describe.

    This is a "live" monitor, and will show you the status on all configured site links.

    http://blogs.technet.com/b/drrez/archive/2011/02/14/microsoft-lync-server-2010-resource-kit-tool-bandwidth-policy-service-monitor.aspx


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.

    Monday, April 23, 2012 9:08 AM
  • Thanks Lasse,

    When running that tool, all the links are showing zero utilization - not sure if the tool is able to show any more detailed information? 

    I should state that this Lync implementation is not live, there no Lync clients out on the corporate network, and I'm not expecting any traffic on the WAN site links at this point.

    It just seems to be an issue when accessing as a remote user.   At this point I think it must be because I have misconfigured CAC.  And because it is happening for a conference and not peer to peer for the remote user, then it is probably the relationship between the front end server pool and Edge server / remote user.  

    I have a local / central site defined in CAC with no bandwidth policy applied.  Initially the subnets assigned to this central site were just the LAN subnets for the central site that I knew would have Lync clients running on them.  Then as part of troubleshooting decided to add the Edge Internal IP, and then Edge external IPs as subnets associated with this central site.  Still getting the same problem though.

    Its around about times like now where I wonder if it is something simple like a service needing restarting so I'll double check things like this.   If you have any other ideas it would be greatly appreciated - a bit stuck.

    Regards,

    James

    Monday, April 23, 2012 7:07 PM
  • Found simple resolution.

    I didn't have Enable Audio Alternate Path and Enable Video Alternate path ticked in the Region settings.   I thought these settings only applied to calls that were not able to be completed across WAN site links due to bandwidth polices (i.e. thought you would enable the settings if your remote site had a PSTN gateway or Edge server and could use these for calls if the WAN link was congested).  However it also turns out that if not enabled will result in the scenario I describe above.

    Thanks



    • Marked as answer by SL32 Tuesday, April 24, 2012 8:46 PM
    • Edited by SL32 Tuesday, April 24, 2012 8:50 PM
    Tuesday, April 24, 2012 8:46 PM
  • Don't you get an insufficient bandwidth anymore? We have e.g. all our internet traffic going through the same MPLS WAN link as the normal audio traffic. Implementing this would route the traffic we want to squeeze out over the same wan, but a different path. So this would be the same as disabling CAC. 
    In most cases this probably works fine, but still not with correct CAC i'm thinking?


    with kind regards, Tim Nagels System Administrator Applications

    Tuesday, August 12, 2014 2:10 PM
  • I've same issue...

    If  I Enable Audio Alternate Path and Enable Video Alternate path, it solves the problem...

    But.. I  don't understand it...

    Wednesday, August 13, 2014 12:09 PM