> 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.
My two cents is that it is not worth littering the sipXbridge with all kinds of logic aimed at compensating for terminally-illed SIP implementation specially when this logic is known not to address 100% of the problems with these ITSPs. There is a certain SIP baseline we should expect from ITPSs and those that fall below that line will simply not be supported. _______________________________________________ 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/
