none
when users mute themselves for a long time, they can't unmute

    Pertanyaan

  • We have many users who mute themselves for many minutes of a conference call.  Then late in the call they want to unmute so they can join the discussion, but they cannot be heard.

    Is this a bug in Lync, or something with their audio hardware (plantronics blackwire usb headsets and p540 usb handsets) disconnecting after one-way use, or something with the sip trunk provider (intelepeer)?

    Any leads would be great!

    thanks!

    Wes

    16 Februari 2012 18:30

Jawaban

  • Just an update - after doing some captures with the SIP trunk provider on both sides of their infrastructure it was determined that the audio was surviving all the way through to the downstream provider.  The SIP trunk provider disabled silence suppression on our trunks and we have not been able to repro the issue since...
    • Ditandai sebagai Jawaban oleh pesospesos 20 Juni 2012 16:23
    20 Juni 2012 16:23

Semua Balasan

  • Hmm, this sounds like the call has one-way audio issue after some time in call.

    We are actually working thru a similar issue with a SIP trunk provider... ;-)


    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public

    17 Februari 2012 1:30
  • thanks Matt - who is your provider?  have you made any headway?  so the issue is hardware independent and is happening on the trunk itself?

    thanks!

    17 Februari 2012 3:06
  • Does Lync client not display mic not working at some point during the call. I have had situations where plantronics mic stops working and reconnecting the device solves the issue or dropping the call and calling again solves the issue.

    Regards Herbert Zimbizi

    17 Februari 2012 6:48
  • according to the users there is no indication that anything is wrong - it just doesn't work.  we have told them to try the workaround of switching to "pc mic and speakers" and back to the device next time it happens to see if that pins it down to the hardware, or if it's something with the sip trunk...
    17 Februari 2012 6:50
  • Hi,

    Do the users who have this issue work in internal network or external network?

    Do they use the same PC and handsets?

    Please try to use a different handset to have a test about this problem.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    20 Februari 2012 6:16
  • Hi Sean,

    All of our users connect via edge as the lync servers reside in datacenters.

    The machines vary hardware-wise but all run Windows 7 32bit or 64bit (pro or enterprise).

    Everyone that has reported the issue thus far is using either a blackwire c220 headset or polycom p540 handset.

    20 Februari 2012 6:46
  • Hi,

    It looks like the Lync edge server cause this issue.

    Do you use NAT or assign three public IP address for the external interface?

    Please try to find more logs about this issue on the edge server. You can use the Lync server logging tool to get more trace message about this issue on edge server.

    About Lync server logging tool, please read the following articles:

    http://technet.microsoft.com/en-us/library/gg558599.aspx


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    21 Februari 2012 6:22
  • Hi Sean, what specifically is it that makes you think the problem lies with the edge server?  We do use NAT for each of the 3 ip addresses on the edge server.
    21 Februari 2012 8:35
  • Hi Sean,

    All of our users connect via edge as the lync servers reside in datacenters.

    The machines vary hardware-wise but all run Windows 7 32bit or 64bit (pro or enterprise).

    Everyone that has reported the issue thus far is using either a blackwire c220 headset or polycom p540 handset.

    Hi,

    I misunderstand this post.

    Do you mean all of your users log in lync client on external network and connect via lync edge server, not only the users who have the issue?


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    21 Februari 2012 9:05
  • Exactly - all Lync users connect via edge, not just the ones having the problem...
    21 Februari 2012 9:14
  • If everything looked good in the Edge config, try looking at your Lync trunk configuration with the SIP provider.  There are several options you can only change via Lync powershell, but odds are one of those options needs to be disabled (RTCPActiveCalls, for example) - it probably isn't supported by the SIP provider. 
    02 Maret 2012 21:13
  • A user has reported back that changing the audio device to something else and back again does not resolve the issue.
    08 Maret 2012 19:23
  • Hi Matt, any progress on your sip trunk issue?  Still trying to pin this down on our side.  Have a case open with Plantronics to research it from that end.
    09 Maret 2012 15:04
  • Pesospesos,

    You might want to run wireshark or netmon on your edge (and possibly the effected client )and recreate the issue.  A router or firewall somewhere might be closing that connection. It sounds like the inbound media stream is dropping due to lack of activity. 

    You also can try to reproduce the issue on your own as duplicating this during a meeting and getting the affected user to run tracing tools might be a bad idea. 

    Once you recreate the problem make sure the client is still streaming audio outbound.  If it is, check to see if its reaching the edge nand what happens after. Let us know what you find.  If i remember correctly wireshark has an option that will allow you to graphiocally see the audio streams and tell you if an when the stream ends by ip and port.


    BBB

    09 Maret 2012 22:01
  • Will try to make some time for that.

    Worth noting that 100% of the reported issues happen when users are dialed into external conference bringing services.  (of course that is the typical muting scenario)

    09 Maret 2012 22:03
  • Hey that changes it :) if you're sure about the 100% thing look at the connection between the mediation server and the your audio gateway as well.  If its only happening on the calls to the pstn its likely that the leg is dropping there.

    BBB

    09 Maret 2012 22:18
  • We have no gateway, just a sip trunk, which is why I am interested in Matt's post above and any subsequent updates :-)

    Lync is relatively new in the org, however, and the conference call scenario is really the only scenario where a user would ever mute themselves anyway.  So I have asked staff to start holding any internal staff-only conf calls via Lync itself rather than calling into an external bridging service to see if the problem can be repro'd in a pure Lync environment.

    09 Maret 2012 22:22
  • Peso,

    I expect if your scenario is the same as ours, you will not experience this in Lync calls. (as opposed to Lync SIP trunk calls.)

    We have been doing some thorough packet capturing at the SIP trunk provider level (working with SIP trunk provider) and, at the moment, all indicators are that the SIP trunk provider's downstream PSTN/carrier provider (you know the big names, i won't mention names) are for some reason dropping the Lync originating side of the conversation. The way we know this is we have done an RTP capture and at the SIP Trunk provider level they can see/record both the Lync originating side of the conversation AND the carrier originating side, even after the remote party says they no longer can hear the Lync user. (raised eyebrows)

    So:

    1-Lync Client <---> 2-Lync-Mediation-Server <---> 3-Lync-Firewall <---> 4-SIPtrunk-provider <---> 5-SIPtrunk-provider-DownstreamCarrier <---> 6-remote telephone

    There is 2 way audio the whole way through #4 even after #6 reports not hearing #1.

    Since this is not resolved I'm a little slow to name the SIP trunk provider, but I'm glad to talk privately. DM @matthewlandis on twitter

    What we currently are experiencing is very hit or miss. The 1way audio can start in several minutes, or it might be 40minutes or the conversation might be fine. Really makes it hard to nail down.

    In all this we have had some very interesting conversations with the SIP trunk provider around downstream carriers reliability in completing calls and completing calls in a timely fashion.


    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public


    10 Maret 2012 4:13
  • Just an update - after doing some captures with the SIP trunk provider on both sides of their infrastructure it was determined that the audio was surviving all the way through to the downstream provider.  The SIP trunk provider disabled silence suppression on our trunks and we have not been able to repro the issue since...
    • Ditandai sebagai Jawaban oleh pesospesos 20 Juni 2012 16:23
    20 Juni 2012 16:23