SIP2012 :: Redefining SIP

Edvina today launched SIP2012 – a project to try to redefine SIP in the eyes of all customers to our industry. We need to go beyond the 10-year old RFC and use all the solutions developed by the IETF and the SIP Forum during 10 years of SIP version 2.0. We’re not defining SIP 3.0 – but trying to combine a set all the specifications added during this time into a reference profile that customers can refer to and use when buying SIP devices – phones, servers, chat clients, PBXs and much more. 

What’s the current state?

It’s very hard for customers to clearly specify functionality required. If they refer to RFC 3261 as a base RFC, that would include S/MIME which is almost never implemented. RFC is updated by 13 RFCs, added to by quite a lot of RFCs and there are 5 verified bug reports (ERRATA) against the text in the RFC. 

An example: A large bid for a new telephony platform

Let’s start the discussion with an example. One large bid from last year specified the following standards as requirements:

  • RFC 3261: SIP version 2.0
  • RFC 3263: Locating SIP Servers
  • RFC 3550: Real-time Transport Protocol (RTP)
  • RFC 3551: RTP Profile for Audio and Video Conferences with minimal control
  • RFC 3487: Priority mechanisms for SIP
  • RFC 2833 or 4733: DTMF signalling
  • RFC 4855/4856: Media Type Registration of RTP Payload Formats
  • RFC 3611: RTP Control Protocol Extended Reports
  • RFC 5391: RTP Payload format for G711.1
  • RFC 3711: The secure Real-time Transport Protocol
  • RFC 5246: The Transport Layer Security (TLS) Protocol
  • RFC 2475: Diffserv
We sent back a lot of questions on this, as there really was no Open Source implementation that could state that it fully support all of these RFCs. Some of the requirements was also hard to understand from an implementation standpoint. Support for SRTP is one thing, but what about key exchange? SDES, Mikey, Zrtp or DTLS? Do they really require S/MIME, as specified in RFC 3261?

What is your opinion? Do you have a good specification that could be useful for other people? Please share!

Reference implementations are important!

We encourage Open Source projects to support the profile and take some extra steps to build reference implementations and test them at the SIPit test events, organized by the SIP forum. Edvina will participate and help tests by building self-test platforms where possible, as we’ve done for TLS, SIP Identity, early media and much more during earlier SIPit events.

Kamailio and OverSIP Open Source SIP Servers are working on implementing SIP Outbound, the first part of SIP2012. We need clients that support it so we can test it for interoperability. Please join this effort!

To find out more – click here for the SIP2012 web with a presentation of SIP Outbound – the first part of the SIP2012 profile.

Comments

Comments are closed.