26 Feb
2009
26 Feb
'09
10:26 a.m.
2009/2/26 Olle E. Johansson <oej(a)edvina.net>et>:
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
<ibc(a)aliax.net>