There is tremendous value in terms of performance and scale to providing a direct media path between these different client, and Microsoft is moving in that direction. Either way, as depicted in the following simplified diagram, the signaling and media paths are basically the same in that they both must traverse the entire backend infrastructure. The Lync to Skype scenario is quite different though as this use-case is more about bridging enterprise and consumer solutions in which it can be argued that the two clients would rarely be on the same network. So in the event that a Skype user is calling a Lync user on the same network the media would take the long way around and effectively be hairpinned back into the same network.įor native Lync connectivity the topic of media traversal is well documented and the value of negotiating a direct media connection can be quite obvious.
So even though the calls are basic peer-to-peer scenarios the media must still traverse the Skype back-end infrastructure regardless. The signaling gateways in the Skype cloud would then facilitate the connections between the different clients allowing each to negotiate a media connection with the media gateways. This “Version 1” capability was actually provided by use of media transcoding gateways in the Skype cloud which would allow both clients to utilize their own, unique pre-existing audio codecs. Last year Microsoft added support for peer-to-peer audio calls between Lync 2013 clients and newer Skype clients. While most of this new information was focused around direct video compatibility with Lync 2013 clients, there will be some advancements in audio calling as well. BackgroundĪt the latest Lync Conference Microsoft released more details regarding further integration plans between Lync 2013 and Skype. This article has been in the works for a while and in the meantime fellow MVP Johan Delimon has also posted a brief article covering just the audio codecs in Lync 2013. But due to the latest announcements around Lync and Skype integration it seems appropriate to first take a closer look at one of these codecs in particular before diving into the rest. There's not a great deal online about troubleshooting these issues so any help would be greatly appreciated.The original intent of this article was to review the current list of supported audio and video codecs in Lync 2013 and attempt to explain what each one is used for given that the list has grown quite a bit over time. In terms of what is logged on the RMX it gets a BYE SIP signal but I believe this is sent as a result of this error. This is in a lab environment at the moment. Ms-diagnostics: 1033 reason="Previous hop server component did not report diagnostic information" Domain="" PeerServer="" source="" TL_INFO(TF_PROTOCOL) 09F8.0994::-12:27:57.230.00000005 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265)) ĭirection: incoming source="internal edge" destination="external edge" When making a call you get the following errors registered in Lync which I captured via debugging logs.
I've followed the guide, checked it several times and the setup appears to be sound on Lync and the Polycom side. However, federated users cannot connect to the meeting rooms. External Lync users registered to the pool which is linked to the DMA can call the VMRs registered to the DMA. The Lync environment has an Edge server which is working fine for external users and federation (all have been thoroughly tested).
These are not registered VMRs but access via the static route as documented in the deployment guide. There is one RMX registered to the DMA which is working fine for internal calls to meeting rooms, e.g. We've setup a Polycom DMA which integrates into Lync as per the UC deployment guide.
0 kommentar(er)
