AV failures in UCMA on an IPv6 only server


I recently handled a case where the customer was reporting consistent AudioVideoCall failures when running on a server that was configured for IPv6 only.  If it was configured for IPv4 or dual stack, then it would work fine.

When the issue was hit an exception would be thrown similar to this:

TL_VERBOSE(TF_COMPONENT) [2]1604.01D4::07/10/2015-19:43:29.000.00010996 (Collaboration,MediaAsyncResultT<Ex>.Complete:asyncresult.cs(625))(00000000022B3598)<GenerateOfferWorkitemAsyncResult_22B3598> Owner: <MediaSessionAgent_19142F1> Completing operation: Microsoft.Rtc.Collaboration.AudioVideo.MediaSessionAgent+GenerateOfferWorkitemAsyncResult, Exception: OfferAnswerException [Exception: Microsoft.Rtc.Collaboration.OfferAnswerException
> FailureReason: ServerInternalError
> DiagnosticsInformation: Microsoft.Rtc.Signaling.DiagnosticsInformation
> SignalingHeaders: System.Collections.ObjectModel.ReadOnlyCollection`1[Microsoft.Rtc.Signaling.SignalingHeader]
> DetectionStackTrace:    at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at Microsoft.Rtc.Signaling.RealTimeException..ctor(String message, Exception innerException)
at Microsoft.Rtc.Collaboration.OfferAnswerException..ctor(OfferAnswerFailureReason reason, String message, Exception innerException, IEnumerable`1 signalingHeaders, DiagnosticsInformation diagnosticsInformation)
at Microsoft.Rtc.Collaboration.AudioVideo.MediaSessionAgent.CreateOfferAnswerException(OfferAnswerFailureReason type, Exception e, UInt32 errorCode, RtpEndpoint endpointForDiagBlob)
at Microsoft.Rtc.Collaboration.AudioVideo.MediaSessionAgent.ProcessGenerateOfferWorkitem(GenerateOfferWorkitemAsyncResult workitem)
> Message: An internal media error occurred
> Source: Microsoft.Rtc.Collaboration
> HResult: -2146233088
Inner Exception: Microsoft.Rtc.Internal.Media.EndpointException
> InnerHresult: -1073463292
> Message: Cannot get the transport parameter.
> TargetSite: Void EngineGetTransportParameter(CTransportHandle, UInt32, Void*)
> StackTrace:    at Microsoft.Rtc.Internal.Media.RtpEndpoint.EngineGetTransportParameter(CTransportHandle TransportHandle, UInt32 ulParamName, Void* pParamValue)
at Microsoft.Rtc.Internal.Media.RtpEndpoint.StartListenForConnectivityChecks()
at Microsoft.Rtc.Collaboration.AudioVideo.MediaSessionAgent.StartListenForConnectivityChecksForNewMedia(IList`1 newMediaList)
at Microsoft.Rtc.Collaboration.AudioVideo.MediaSessionAgent.ProcessGenerateOfferWorkitem(GenerateOfferWorkitemAsyncResult workitem)
> Source: Microsoft.Rtc.Internal.Media
> HResult: -2146233088

It seems that in order for UCMA to properly configure the media stack it needs to know exactly what the IP configuration is on the server.

For automatically provisioned applications this is done simply in the topology builder:

However for manually provisioned applications it was not immediately obvious how this could be achieved. Attempting to set the platformSettings.OutboundConnectionConfiguration.DefaultAddressFamilyHint did not seem to help.

It turns out that proper way to configure this is to explicitly set the primary listening address as follows (or specifying a specific IP address if preferred):

platformSettings.ListeningIPAddress = IPAddress.IPv6Any;

The defaults within UCMA seem to always end up as DualStack.  By explicitly setting this listening address, we force it to recognize that we are IPv6 only.

Comments (1)

  1. Akshay says:

    Aaah! I felt dejavu reading this dev issue 🙂 really great to know how to resolve this ! Keep up the good work of knowledge sharing 🙂

Skip to main content