2009/2/26 Olle E. Johansson <[email protected]>: > This is a problem I realize at every SIPit. The implementations are far away > from the IETF world. And the gap doesn't seem to close. > > Basic stuff like DNS is not understood or used by many SIPit attendees so > even trying to mention NAPTR is too complex, and it's necessary for many > security scenarious.
RFC 3263 (Locating SIP Servers) is really complex, NAPTR is really complex, and it's not needed in 99% of current SIP deployments, so vendors don't implement it. If a SIP provider whises to use NAPTR records then all its clients should implement it in their SIP phones (obviously this is unfeasible for now). Solution? don't use NAPTR at all. > The big question is how to close this gap. I have no clue. > - Can we stop the IETF SIP development during a year and work on > implementations, testing and reality checks? AFAIK no one draft or RFC comes with a real implementation. Sincerelly I don't feel to much interest in real implementations aroud IETF. They can join a long maillist thread about exotic SIP issues that will never happen because nobody will implement the required especifications. When I read IETF-SIP maillist and compare their threads with today's SIP implementations, they seems two different worlds. > - Would it be possible to get more implementation guidelines published? Does one of these already exist? where? > We have at least two cases now where an update to the RFC added important > MUSTs: > > - Tel uri - phone-context is now required, which affects all SIP devices > using SIP uri with user=phone > regardless if they use a Tel: URI. > - RFC2833 DTMF is updated and secure RTP is now required I would add all those especifications including new "Require" values, and also those requiring multipart (widely NOT implemented). > The Jabber world annualöy publish a document where they specify "base level > standard compliance" for a client and a server. Maybe the SIP world should > copy this and use it as a way to push changes to the market. There is somewhere an RFC pointing a list of "recommended" RFC's. When I read it long time ago there were a *lot* of specifications there. > If the standardization is too far away from current implementations, we have > a fork. That's not good for anyone. Sure, but who care? This should care to both implementators and designers, but... -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
