On Wed, Jun 16, 2010 at 11:20 AM, M. Ranganathan <[email protected]> wrote: > On Wed, Jun 16, 2010 at 11:07 AM, Martin Steinmann <[email protected]> wrote: >>> >>>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? >>> >> >> If this would allow us not to end up with regressions in the field (i.e. >> production installations that work today on 4.2 but would no longer work >> after this change), then I would vote for this. Especially since some users >> might not have a good alternative ITSP to go to because there either is >> none, or because the alternative would cost a lot more money. >> --martin >> >> > > > > I hope the following compromise will suffice: > > Because these hacks have been in the field for some time and are > localized and because people may be depending on such ITSPs to work > 90% of the time by now. I will leave the hacks in there but they will > be guarded by a hidden boolean flag in sipxbridge.xml called > strict-protocol-enforcement. > > That flag will be hidden and set to "true" by default and I highly > recommend it not be set to false. I would not look favorably upon > problem reports where the flag has been set to false. > > Thanks > > >> >> >> > > > > -- > 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/ > This has always been a gray area. I've posted the phrase on the lists many times... "Not all ITSP's are equal." as well as "Not all SIP TRUNKS are equal."
I think at some point a line should be drawn to determine what an ITSP should be able to support (in definitions) in order to maintain some viability. I see both sides, for example Martins comments about different parts of the world and the ITSP choices there. Example: Australia. I can connect and use Callcentric with sipx, but callcentric sends DID info in TO not the INVITE. In some majorrt metro markets there, they seem the be the largest player in the US_with_Australia trunks. I am seeing this same type of thing in Columbia. Of course I can always use an external SBC. So I agree it should be "loosened" to a point... then I see Ranga's issue... to what point. I like seeing this discussion though. It's healthy. _______________________________________________ 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/
