> >> >> Hello, >> >> I had previously put in some hacks to compensate for protocol errors >> > >from ITSPs such as responses to SDP solicitations that would return > >> an OK with NO SDP body. There are even those very badly mannered ITSPs >> that randomly return OK to INVITE with no contact header at all. Very >> bad form indeed. >> >> I am removing those hacks from sipxbridge that were put in there to >> compensate for such behaviors. Unfortunately, it becomes too >> complicated to handle such situations gracefully and those hacks do >> not work in all cases anyway, Henceforth, sipxbridge will follow the >> process of tearing down the call when critical protocol errors are >> noticed. You will notice changes to this effect going into 4.2.1 This >> may mean that your ITSP that was hitherto working sometimes may cease >> to work in a consistent way. I will also be pruning the interoperable >> providers list and removing at least one such provider from that list >> which is known to exhibit such errors. >> >> Please note that for sipxbridge to work, the provider must correctly >> implement the SIP protocol. >> >> Thanks >> >> Ranga. >> > You are outlining a decision that I am sure was taken after some > deliberation based on one or several specific incidents. It would help if > you could provide some of that background. As you know we have a long > history of 'protocol purism', which generally has not served us well. > sipXecs always ended up as the incompatible system and users pointed at > other systems that apparently worked. If you are Microsoft or some other > monopolist you can expect the world to adapt to you, but for everyone else > that is not a good strategy. > > But at some point, putting in an attempt to adapt to a really bad implementation can end up introducing errors that manifest when talking to a different, correct implementation. It's good to be flexible, but there are limits - sometimes when you discover that you're in a deep hole the right thing to do is to stop digging.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
