Word of warning
This may sound like I'm trying to disuade you from persuing this endevor. Far from it, SIP is a fun protocol to work with (eventually) and it's very rewarding to see it all come together. You will enjoy a great deal of satisfaction at having gotten such a beast to work, and I wish you the best of luck in shaping it to your will! However, be prepared: SIP is a frustrating beast to work with.
The following timeline is based on my own experience, though I've shortened timelines somewhat due to there being two of you. Our dev cycle lasted nearly a year, but I was both the lead, and only programmer on the project, and that time includes all the work done on the UI, requirements coordination, planning, documentation, etc.
Week 1 & 2
SIP is a complex specification, with many extensions and peculiarities, especially relating to firewalls, forwarding, branching and joining. I would recommend you start looking up RFCs, and simply devote a good amount of time to reading the signalling specs, and any extensions you will need for your application, including at a minimum, the base specification, the SDP specification, and the ICE protocol specification.
That should occupy about a week if you're doing it right, and full time. For week 2, consider which extension specifications you'll need (presence indications, preconditions, conferencing, GRUU, etc) and spend the time to read those as well. Drill each other on them, it's a lot of information, and it's relatively complex in terms of how they all inter-relate to each other.
Break out the protocol analysers (Wireshark, etc) and see what the apps you have are doing on the wire. Having read the specs, you'll now be in a good position to understand why various SIP products have difficulty playing nice with each other, and, an idea of how to start working on your own app.
Week 3-6
Even with a decent toolkit, you will spend the better part of a month getting SIP to reliably do what you want it to in communicating signalling information, and writing the required infrastructure to respond to SIP signals. There are a crazy number of edge cases, and every pitfall you can imagine in concurrent processing is now magnified by the fact that you have three independent agents, some of whom will have very high latency, unreliable network connections, all trying to co-ordinate regarding the same transaction.
Don't take shortcuts, code, test, code more, look for faults and edge cases, and keep going. The RFCs help A LOT in understanding the problems you will run into, but some of it just has to be trudged through.
Week 7 & 8
Depending on the requirements for your application, just establishing the underlying connection between end-user agents will rightly occupy most of your effort to create a reliable product. You will, between the two of you, likely spend the next couple of weeks getting this part to work for the first time, and likely uncountable hours diagnosing edge conditions throughout the rest of the dev cycle of the app. Remember that there are edge cases here which require a media proxy, and a no-win edge case where the user is so badly firewalled that nothing can be done. Don't forget to handle them.
Week 9-11
At this point, your phones should (fairly) reliably connect to each other, depending on your experience and network knowledge, over fairly strict firewalls as well. The preconditions spec is very useful for decreasing perceived delay here, as you can hold off on ringing until the network layer has already connected. My experience will not inform the next layer (protocol) very well, as with Java, the media encoding and decoding was handed to me on a silver platter, aside from quicktime, which I had to do myself. I would chalk up a week or two for getting the protocols working nicely, and communicating protocol information reliably via SDP, but this may be a very optimistic estimate on my part.
Add another week if you've never worked with RTP/RTCP before, as while they're not complex per-say, properly responding to the feedback you get from RTCP can be challenging, and is somewhat of a dark art, though quite critical to ensuring optimal network utilisation and media quality.
Week 12+
Likely, at this point, you'll realise that one or another SIP product you want to be able to connect with, doesn't like your implementation, sometimes for reasons utterly inexplicable. If you need to support finicky products, you will spend the next few weeks to a month diagnosing why. If your product is proprietary, you probably don't care about this step, but it's also a way of double checking how badly you're mangling the spec. (We all do, so don't assume the test product you're using is correct either! Always double check!)
Additional
Bear in mind, the above is mainly intended as an estimate of how long it will take to get a well-written SIP/SDP/ICE based solution functioning, not the app using such infrastructure. UX is king in the iOS world, so make sure your app is compelling, and spend a LOT of time getting it right.
Even if
you use a library to make the coding easier, learn the underlying protocol! It will benefit you tremendously to understand why things work the way they do, and why the SIP universe is full of so many broken products.
