Introduction to the UCMA API - Part 13 - SipPeerToPeerEndpoint
Today will be a short post with no changes to our server or client projects. Currently we use the SipEndpoint class to register ourselves with the Microsoft Office Communications Server and create a dialog between our client and our server. Some of you may have also noticed the SipPeerToPeerEndpoint class and wondered what the exact difference is.
I must admit that I was a bit confused at first too. My first thoughts with SipPeerToPeerEndpoint were that it did not require an INVITE dialog in order to send messages. This is not true – it requires an INVITE dialog as with SipEndpoint. The big difference between the two is a SipPeerToPeerEndpoint does not register with an Microsoft Office Communications Server and therefore does not authenticate to it. This means that for some uses that require authentication (such as conferencing) SipPeerToPeerEndpoint will not be useful.
SipPeerToPeerEndpoint is very useful, however, when you do not have an Microsoft Office Communications Server and you are using the UCMA API as a means to simply send SIP messages between endpoints. In terms of how our code would change for our client and server if we used SipPeerToPeerEndpoint, the only real change would be to remove the logic that calls BeginRegister and BeginUnregister in both.
Keep in mind that in order for SipPeerToPeerEndpoint to be successful there must exist proxy servers that can direct communications between the two endpoints, as there is no Microsoft Office Communications Server to help. Really, the key to determining whether you use one or another is whether you require authentication with the Microsoft Office Communications Server. If you require authentication, then SipEndpoint must be your choice.
I decided not to post any code today because the code we already have should be instructive enough for how to use SipPeerToPeerEndpoint correctly.