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.