Warning word
It may sound like I'm trying to persuade you to abandon this endevor. Away from it, SIP is a fun protocol to work with (ultimately), and it’s very useful to see how it all comes together. You will receive great satisfaction from receiving such a beast, and I wish you the best of luck in creating it according to your will! However, be prepared: SIP is a disappointing beast to work with.
The following timeline is based on my own experience, although I have reduced the time somewhat because there are two of you. Our dev cycle lasted almost a year, but I was a leader and only a project programmer, and this time includes all the work performed in the user interface, coordination of requirements, planning, documentation, etc.
Week 1 and 2
SIP is a complex specification with many extensions and features, especially those related to firewalls, forwarding, branching, and combining. I would recommend that you start your search for RFC and just spend enough time reading the signaling specifications and any extensions you need for your application, including at least the basic specification, SDP specification, and ICE specification.
This should take about a week if you do it right and full time. For the second week, consider what extension specifications you will need (presence indication, prerequisites, conference calls, GRUU, etc.) and spend time reading them. Check each other on them, this is a lot of information, and it is relatively difficult in terms of how they are all interconnected with each other.
Break down protocol analyzers (Wireshark, etc.) and see what applications you have on the wire. After reading the specifications, you will now be in a good position to understand why different SIP products have difficulty playing with each other, and how to start working on their own application.
Week 3-6
Even with a decent set of tools, you will spend most of the month receiving SIP in order to reliably do what you want to transmit signaling information and write the necessary infrastructure to respond to SIP signals. There are a crazy amount of edge cases, and every trap you can imagine with parallel processing is now increasing due to the fact that you have three independent agents, some of which will have very high latency, unreliable network connections, everyone is trying to coordinate relatively the same transaction.
Do not use shortcuts, code, test, code anymore, look for errors and extreme cases, and keep moving. RFCs help LOTs in understanding the problems you face, but some of them just need to be dragged.
Week 7 and 8
Depending on the requirements of your application, simply establishing a basic connection between end-user agents will rightfully occupy most of your efforts to create a reliable product. You, between you, will probably spend the next two weeks getting this part to work for the first time and probably countless hours diagnosing extreme conditions throughout the entire application development cycle. Remember that there are edge cases here that require a media proxy, and a win-win case where the user is so poorly protected by the firewall that nothing can be done. Do not forget to handle them.
Week 9-11
At the moment, your phones should (fairly) reliably connect to each other, depending on your experience and knowledge of the network, through fairly strict firewalls. The prerequisite specification is very useful for reducing the perceived delay here, as you can hold it until the network layer is already connected. My experience does not inform the next level (protocol) very well, as in the case of Java, the encoding and decoding of multimedia was transferred to me on a silver dish, except for the quick time that I had to do myself. I earned a week or two to work well with the protocols and reliably transmit protocol information through SDP, but this can be a very optimistic assessment on my part.
Add one more week if you have never worked with RTP / RTCP before, since although they are not complicated for one, responding correctly to the feedback you receive from RTCP can be a daunting task and is kind of dark art, although very important to ensure optimal use of the network and the quality of the environment.
Week 12+
You will probably understand at the moment that the particular SIP product you want to contact does not like your implementation, sometimes for reasons that are completely inexplicable. If you need to support finished products, you will spend the next few weeks a month to find out the cause. If your product is proprietary, it probably doesn't matter to you, but it is also a way to double-check how poorly you manage the spec. (We all do this, so don’t assume that the test product you are using is correct too! Always check!)
Additional
Remember that the above is mainly intended to estimate how long it will take to get a well-written solution based on SIP / SDP / ICE, and not an application that uses such an infrastructure. UX is the king in the world of iOS, so make sure your application is convincing and spend a lot of time on the right decision.
Even if you use the library to simplify coding, learn the basic protocol! It will be of great benefit to you to understand why everything works the way they do, and why the SIP universe is full of so many broken products.