Category Archives: Audio/Video MCU
I am currently investigating an issue I have internally, and have heard someone else having on the Technet forums: http://social.technet.microsoft.com/Forums/en-US/ocsconferencing/thread/f9512694-c298-4951-b6d6-0d240ccd0397
The issue is that when in a communicator conference call, you cannot send DTMF tones to a PSTN participant. The scenario is as follows:
- Communicator call, or communicator conference call is initiated
- User invites a PSTN number to that conference call
- PSTN number requires DTMF tones, whether it is a conference bridge, or an attendant menu, could be various situations
- No DTMF is received by the PSTN number.
So far, I have been able to confirm a couple of things. This happens with CS2010 as well as OCS 2007 R2. Internally we use a Dialogic DMG2120 gateway, and I have confirmed that I do not see DTMF on the gateway’s SIP side from OCS.
I am using this post to hopefully get some partners and customers to try this scenario, and see if they have the same issue. I would find it hard to believe that this is a bug in OCS/CS2010 that Microsoft has not addressed, but I am hoping to find a common configuration among people experiencing this issue so we can maybe narrow it down.
Typically this is a gateway issue, however like I said, I have not seen any DTMF come from OCS to the gateway when in the conference call.
Please respond in the comments with a brief description of your OCS setup and gateway/SIP trunk, and if you experience this issue or not.
It is identified in the above article. AVMCU does not support DTMF Relay. Thanks to the commenter!
It has been a while since I have had a post over here, guess you can blame the holiday season as well as the busy beginning of the year at Winxnet. Anyways, I have been working with PSS on an issue with external live meeting through the edge for quite some time now, and with that has been lots of performance monitor collection, after clicking through all of the different collectors multiple times, I decided to create some templates to have for future use and wanted to share them. Its nothing special, no awesome script or anything complicated, but a very basic tool that may be useful to anyone going forward.
Above is a link for access to these files on my sky drive. If you have any issues accessing these please leave a comment or contact me via email and I will get them to you.
They are very easy to use, once downloaded, open Reliability and Performance Monitor from either your Front End or Edge Server…
Expand “Data Collector Sets” and right click on the User Defined folder. Choose New->Data Collector Set
Name the collector set whatever you would like and make sure to choose Create from a template.
Click next to access the next page in the configuration wizard. Choose Browse and locate the XML file you downloaded containing the template information. Once you select that file the page should look like this:
The next two screens will ask you where to save this file, I would suggest a drive with plenty of space as these can get very large depending on the amount of traffic on your server and how long they are running.
When you are ready to collect data simply right click on the set you created and choose start.
Once you are ready to analyze data, or send to Microsoft PSS for data analysis you simply choose stop, and you will have a file in the location you specified. Microsoft PSS uses a tool called PAL(Performance Analysis of Logs) which is an open source application written by a Microsoft employee. This tool can be found here: http://www.codeplex.com/PAL If you are feeling up to performing some of your own analysis this is a great tool to use. I may try to post some more detailed information on using this tool soon.
The templates included in my link include the following Counters:
All <LC: > Counters
Hopefully soon I will have a new post describing the fix for this strange live meeting issue, until then, Enjoy!
Some organizations will deploy LiveMeeting either without the existence of OCS, or without OCS Audio/Video Conferencing being enabled. By default, the conferencing addin for outlook has a Schedule A Conference Call button regardless of the environment you are connecting it to.
There is a registry entry that can be used to disable this button:
1. Locate and then click to select the following registry subkey:
Note Use this subkey for x86-based systems. If you are running a x64-based system, locate and click the following subkey:
2. After you select the subkey that is specified in step 3, point to New on the Edit menu, and then click DWORD Value.
3. Type RemoveConferenceCall, and then press ENTER.
4. Right-click RemoveConferenceCall, and then click Modify.
5. In the Value data box, type 1, and then click OK.
6. On the File menu, click Exit to close Registry Editor.
If you wish to remove this setting, simply change the Value to 0 and the button will be available again.
A full list of livemeeting registry keys can be found here: http://technet.microsoft.com/en-us/library/dd637135(office.13).aspx
On a recent deployment I ran into an issue where everything was working correctly except an external user trying to join or create an Audio Video Conference. The customer had an enterprise edition consolidated configuration behind an F5 Load Balancer. Doing our initial sip traces we were able to see a 500 error when the external user would try to join or create a conference.
Start-Line: SIP/2.0 500 The server encountered an unexpected internal error
ms-diagnostics: 3080;reason="Internal Error: AddUser failed";source="front end server fqdn"
I removed most of the trace except the important parts. What you will see in the above trace is the SIP 500 error, and then at the bottom the AddUser is failing on the front end server. This exact symptom with an enterprise pool behind load balancers points to this KB article: http://support.microsoft.com/kb/946091. This fix explains an issue with the load balancer being in DNAT mode instead of SNAT mode. However our F5 was using SNAT for all of the OCS traffic, and the pool setting was correctly set to not be in DNAT mode.
Running more traces another error popped up which was a SIP 403 Forbidden:
SIP/2.0 403 Forbidden
SERVER: RTCC/126.96.36.199 MRAS/2.0
ms-edge-proxy-message-trust: ms-source-type=EdgeProxyGenerated;ms-ep-fqdn=Edge Internal interfacefqdn;ms-source-verified-user=verified
Ms-diagnostics: 9006;source="Edge Internal interfacefqdn";reason="Forbidden";component="Media Relay Authentication Service"
This basically means that the front end server is not able to get media relay authentication from the edge server A/V internal interface.
If this is happening you will also see an error in the event logs:
Log Name: Office Communications Server
Source: OCS Audio-Video Conferencing Server
Date: 9/25/2009 4:12:14 PM
Event ID: 32018
Task Category: (1017)
Computer: FRONT END SERVER FQDN
The Audio-Video Conferencing Server encountered an error when requesting credentials from the A/V Edge Authentication Service.
A/V Authentication Service Service URI sip:EdgeInternalFQDN@swk.pri;gruu;opaque=srvr:MRAS:HqCEupOMck6C3onsDHul1wAA, Reason: The operation has failed. See the exception’s properties as well as the logs for additional information.
Cause: The Audio-Video Conferencing Server cannot communicate with A/V Authentication Service.
Check the A/V Authentication Service is alive and that network connectivity exists.
Connectivity was available through the internal edge VIP as well as each individual edge server’s internal interface. Also, if you ran an A/V Conferencing Validation on each of the front end servers it would succeed on all tests.
I ran through this with PSS and there were two things we discovered. The first potential issue was on the Internal tab setting of the edge server. Per the Microsoft documentation when doing an enterprise deployment the name that should be listed on the “Internal Servers Authorized to Connect to this edge server” setting is the pool FQDN, not each individual front end server. There has been some debate about whether you should add the FQDN of each front end server to this list as well, because we were seeing the front end servers get denied access to the A/V Authentication service we decided to try it anyways.
The other change that was made was in the forest global settings section. On the general tab you specify your internal SIP domains and you check one for the default routing domain. In this case the customer AD domain was different from the SIP domain, both were listed, however the AD Domain was checked as the domain to be used for the default routing. Once we changed that setting to have the SIP Domain as the default routing domain and restarted the services on the front end servers, A/V conferencing started functioning properly.
I am hoping I can remove each setting and try to narrow it down to one ,but either way the internal interface setting has proved to fix some funky issues in deployments, so both of these may want to be set regardless.