Regarding the technology stack, I'll start by saying that it is not SIP/RTP/ICE which may surprise some people. We had prior experience of that (previous consulting for a major telco), but choose to not go that route. Those protocols are seriously overcomplicated (design by committee...) and the only benefit it would give us is interoperability - which is often important, but not for this project.
So call control, media stream and NAT punch-through protocols are entirely custom. Might sound crazy, but if I tell you the server is less than 3k lines of code, and was written in two weeks, maybe not so much?
The call control server is done in Erlang - turned out well so far as we've live-upgraded the servers several times without interrupting any calls. We use iOS apns VOIP notifications for notifying the other peer of the incoming call.
The UDP media stream is peer to peer and carries H.264 for video and AAC-ELD for audio. Since the app is iOS only we could take advantage of the built in hardware video decoder and audio libraries for that. Not to mention the patent licenses for those technologies that come bundled with iOS. We had to develop a jitter-buffer and audio-video syncing solution on top of that of course - that's the most complicated part of the client side.
Edit: I should add that we do not support Symmetric/Carrier grade NAT traversal in this first version. Since it's not possible to establish a direct peer-to-peer connection under such conditions we'll need to add server side support for forwarding the media. That's going to be a major challenge for next year.