> > >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. --martin _______________________________________________ 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/
