> > 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:
Random call drops is obviously no good, but is it really random? These 'bad' ITSPs are all in business and therefore we have to assume that for the majority of their customers it works. 'Random' therefore likely is quite reproducible and relates to specific call flows in combination with sipXbridge. If these problematic call flows failed with most or all IP PBX systems, I would assume the ITSP would make it a priority to fix. Using sipXbridge we now also have a B2BUA and not a proxy to interface with the ITSP. This was the main difference between our system and others that caused most of the incompatibility as far as I understand. What else then is different about our approach compared to others that still makes it more difficult for us to work with what seems to work for others? > >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. It sounds like there are very specific call flows that do not work, such as the ones you identify above. Maybe what you mean by 'tightening' is that these call flows are not supported anymore in that sipXbridge will not make an attempt to fix it, but basic calls or calls using different call flows will still work with that ITSP. Do we know what call flows and end systems ITSPs design against so that we can at least be as interoperable as these scenarios and systems? > > >> 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. In the US it might be true that there is sufficient choice when it comes to 'good' ITSPs, especially if price is not the issue. In other geographies this is not the case. Even in Europe it is still difficult (at least so it seems) to find a sufficient number of ITSPs that would be fully compliant. I could imagine that going to South America or Asia that problem could multiply. Therefore, I continue to believe that in order for us to play in a market and especially as an open source solution, it is up to us to adapt. --martin > >Regards > >Ranga > _______________________________________________ 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/
