On Tue, Jun 15, 2010 at 10:32 PM, Martin Steinmann <[email protected]> wrote: >> >> >>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.
Yes, I was looking at some traces recently provided to me by onRelay. I have also seen similar behavior from a Swiss ITSP ( voipuser ). They must both be using the same infrastructure because they seem to exhibit the same problems. As you know we have a long > history of 'protocol purism', which generally has not served us well. This is really not the same thing. I am talking about basic errors with the implementation of the protocol that makes it difficult to compensate for. Or worse, results in a solution where the solution mostly works but does not always work -- so you get random call drops. Two specific protocol violations: 1. Our design relies heavily on the use of in-dialog re-INVITE and media renegotiation during call transfer. It is a requirement of SIP and of SipXbridge that this flow be supported correctly. If that basic call flow is broken, nothing else works reliably. 2. If an INVITE OK response does not have a Contact header, there is no way to complete the three-way handshake for call setup. > sipXecs always ended up as the incompatible system and users pointed at > other systems that apparently worked. One has to examine the reasons why a particular scenario does not work. For example, it was true that direct communication with the SIPX SIP proxy would result in large message sizes. This is why things were not working in the past but sipXbridge hides that. 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 Microsoft and other monopolists may choose to deviate from the SIP protocol and get away with it. I am not advocating that. There seems to be no shortage of competitively priced correctly functioning ITSPs. Some seem badly behaved enough to be avoided. Regards Ranga > > > > > > -- M. Ranganathan _______________________________________________ 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/
