Yeah, that's a sort of Pandora's box. This name fits IMS very well. In my opinion, it's not the requirement which prevents IMS from leaving the labs. Let's not forget that the whole IMS concept is still very young, and not yet ready to be deployed as a carrier grade network infrastructure. So far I can just think about iptel (Spanish operator) who partially deployed IMS (this might be wrong, I'll check later on). Beginning September I attended the NGMAST conference in Cardiff (Next Generation Mobile Applications, Services and Technologies). A lot of IMS-related topics has been discussed. Part of what I'm about to tell you is based on the discussion and keynotes made during this conference. It seems that the telco operators are not going to implement the IMS as a whole network architecture. They will rather pick up some parts of it (like the SOA, or SIP A/S) where they can make money on it. As of today, there's no mobile device which is IMS Compliant. And this for a very simple reason : I don't know any device mobile who support IPSec. And IPSec is a prerequisite to access an IMS Domain. And that's where the snake bites his own tail. The mobile phone company (Nokia, Siemens, Ericsson ect) are not focusing on making native IMS-compliant phones, because there's no available networks to connect to which such a phone. The telco operators are not moving to IMS because there's no mobile phone who might connect to their network. I see the migration from the Circuit Switched network to IMS as hard as moving the internet from IPv4 to IPv6. I think the people from the 3GPP and the main companies involved in developing IMS should really think on a smooth way to migrate from the current architecture to IMS. It has already be partially done with the "Early-IMS" concept, allowing standard SIP application to connect to an IMS network. Now looking at the list of RFCs from my previous mail, they all do not need to be implemented, except maybe 2 or 3 of them. (3455,3325). SigComp would be very useful as well in the future, but right now, most people says that sigcomp is not really needed. So it's not widely used on the IMS testbeds. The privacy headers are only necessary on a device where you can use IPSec. This leave us with the Private headers (P-Header) and the Private extensions (Asserted and Preferred identities) Well, that's it. It's mainly my opinion, but also based on discussion I had with people involved in the IMS development in big companies. Oh, and no, unfortunately right now I don't have the time to dig into the pjsip core code and implement myself the IMS capabilities, even if I would enjoy it :) But maybe at a later time, once my project is over. Regards, Olivier B. Roland Klabunde a ?crit : > Oh, that sounds to be a lot of work... It seems that this is Pandora's box, > Benny mentioned somewhen :) > > Wouldn't you agree, that this big amount of requirements could prevent IMS > from leaving the labs and getting really successful? > Or do I overinterpret this, and implementing the MUST HAVE could be done > with a snip? > > BTW: Are you working on PJSIP's IMS capabilities? > > Regards > > > > ----- Original Message ----- > From: "Olivier Beytrison" <olivier@xxxxxxxxxxxxx> > To: "pjsip embedded/DSP SIP discussion" <pjsip at lists.pjsip.org> > Sent: Sunday, October 28, 2007 12:31 PM > Subject: Re: [pjsip] REGISTER in IMS and special Headers > > > Hello Roland, > > That's a pretty tough question you asked =) > > Okay I'll try my best to not forget one :) > If we start from this reference : > http://www.pjsip.org/sip_media_features.htm#sip_features all those > features are needed for an IMS Client. > > The one that should be supported as well are : > > RFC3321 and RFC3322 for Signaling Compression > RFC3323 about the Private Field for privacy > RFC3325 (very important) Private Extensions to SIP for Asserted Identity > within Trusted Networks > RFC3329 Security between the UA and First hope > RFC3455 Private Header (P-Header) Extensions to SIP for the 3GPP > RFC3486 Compressing SIP (for SigComp) > RFC3892 should be fully supported for Session Mobility > > > RFC4083 is interesting as well, describing the requirement of SIP by the > 3GPP > > That's it I think. I've based this list on this page > http://www.tech-invite.com/Ti-sip-RFCs.html. > > If anything else comes to my mind, I'll complete the list. > > Regards, > > Olivier B. > > Roland Klabunde a ?crit : >> Hi Oliver, >> >> I'm just curious: Besides the Digest-AKA, which has been integrated to >> PJSIP >> by Benny, and the remarks you sent in your mail: What RFC's would you >> consider to be "mandatory for PJSIP" in order to evolve to a IMS compliant >> UA? >> >> Regards >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > -- Olivier Beytrison Telecommunication Engineer Mobile: +41 (0)78 619 73 53 Mail: olivier at heliosnet.org GPG: 0x4FB83528 http://pgp.mit.edu/
