[Kamailio-Users] Secure VoIP

[Iñaki Baz Castillo]

2009/2/26 Olle E. Johansson <oej at edvina.net>:
> 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 at aliax.net>