On Wed, Jun 16, 2010 at 7:46 AM, Martin Steinmann <[email protected]> wrote: >> >> 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?
Well, you can clamp down the codec to a single supported codec such as G711 ( i.e. filter the request and response SDP to that single supported codec and never re-invite subsequently ). Asterisk has that option ( i.e. can re-invite ). We can support that but at the moment the implementation does not support it. I had started down that path at one point but the logic got convoluted enough that I had to stop. Yes I can place the hack back with a <interoperability>caveat-emptor</interoperability> flag. So sipxbridge will go back to "mostly working" for such ITSPs. It is just true that all call flows have not been tested for such buggy ITSPs. Unless we can do that, it is leaving the door open for customer issues in the field. Do we want to go that route? > >> >>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. Yes. That is correct. You will not be able to do any transfers and call forwarding and MOH will not work either. So the point is such hacks have not been tested in the field for all these call flows and I am getting a bit tired of looking at call flows where the hack just does not work for particular scenarios simply because it has not been tested and debugged. 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? I do not follow the question. I can identify some good ITSPs and others on this list can help there. I can sign up to fully supporting all call flows for non-buggy ITSPs. > > >> >> >>> 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 There is a point there and I am not being religious either. Anything can be hacked with enough effort. However, such things must be well tested in a product before it is put out on in the field. Somebody in a position to make marketing and product positioning statements must let me know if we want to spare the resources to fully test all call flows with such hacks in place. If so, I can do it. If not, I recommend removing such hacks. Best regards Ranga > > >> >>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/
