In a joint press release, the SIP Forum and the IPv6 Forum launches a cooperation in order to raise the pressure on the members and the market to move forward with IPv6 and realtime SIP communication.

“SIP and IPv6 are the two fundamental Internet plumbing pieces of the future Internet. This partnership will allow the SIP Forum and the IPv6 Forum to leverage each organization’s powerful worldwide user base to drive the right knowledge and best practices to the Internet community at large,” said Latif Ladid, President of the IPv6 Forum & Emeritus Trustee Internet Society. “This union will smooth the adoption of these two technologies and spur Internet growth and solid sustainability.” 

“The SIP Forum shares a similar mission and vision as the IPv6 Forum for the broad interoperability and adoption of open standards, next generation Internet-based technologies and services,” said Richard Shockey, SIP Forum Chairman of the Board. “By coming together, our two organizations can help move the industry forward and develop the foundation to fuel a new generation of communications innovation.”

I believe this partnership can lead to a lot of progress. Unified Communication ties people together across boundaries. One of these boundaries will be the IPv4 and the IPv6 Internet. The SIP industry has a responsibility to make sure that this transition works seamlessly and that our customers get products and services that will continue to work as the IPv6-only part of the Internet starts growing - and I’m not only talking about laptops with softphones and chat software - SIP is an application that will run on smartphones, TV sets, pads and all kinds of connected things. A Unified Communication network requires IPv6 to be unified.

Jon Postel captured an approach to make the Internet a more robust place for applications to live in - and added it to RFC793 (the definition of TCP at the time) :

“TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.”.

Robert Sparks has written an article on the SIP Sessions blog about the importance of this for SIP implementations. And he should know. Robert has been managing 25 interoperability sessions with SIP developers. Endless patience with developers that claim that their interpretation of the RFC is correct and that the other side is damn wrong and that’s exactly the reason why their implementation fails the call, the registration or the chat session. I’ve heard Robert saying to me and others many, many times something like: “Yes, there is an issue here, but your app should be more generous and try to handle the situation.” Robert summarizes his thoughts this way:

“Real systems will have imperfections. Systems that use the robustness principle make it less likely that those imperfections will result in failure. Introducing elements that don’t follow the principle negates that robustness, and in real systems,  will cause those systems to fail.”

Read this article named “The Robustness Principle Has Two Parts” 

The document ”The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)“ is now approved by the IESG as a proposed standard. This is an update to RFC3261 that clears up a lot of the issues that has been open in regards to the SIPS: URL scheme.Now we need some clarifications on the “;transport=tls” use and implementation notes, so that all application developers can start working with fixing the applications.I did not realize how bad the situation was until last SIPit where I participated in a TLS interoperability test.  There where too many opinions on how to implement and support TLS in SIP, and too many non-interoperable implementations. A missing piece in many implementations, is DNS NAPTR support. NAPTR plays a very important role in secure SIP connection setups.   The biggest question still remains: What’s a secure call? For Asterisk, we have to do a lot of work here to implement security in the dialplan. But at least we have one document that more clearly explains SIPS: to work with now!

The draft SIP Multiple REFER describes a way to send a call transfer (REFER) indicating setup of a new call to multiple destinations, i.e. initiating a conference. This could be handy between two Asterisk servers, a way to set up a conference on a different server, optimized for conferences.

RFC 3261 (SIP) [RFC3261] is extended by RFC 3515 [RFC3515] with aREFER method that allows a user agent to request a server to send a request to a third party. Still, a number of applications need torequest a server to initiate transactions towards a set of destinations. In one example, the moderator of a conference may wantthe conference server to send BYE requests to a group of participants. In another example, the same moderator may want the conference server to INVITE a set of new participants. We define an extension to the REFER method so that REFER request can be used to refer servers to multiple destinations. In addition, this mechanism uses the suppression of the REFER method implicit subscription specified in RFC 4488 to suppress REFER’s implicit subscription.