+1 -----Original Message----- From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of M. Ranganathan Sent: Wednesday, June 16, 2010 9:40 AM To: JOLY, ROBERT (ROBERT) Cc: sipx-users@list.sipfoundry.org Subject: Re: [sipx-users] Tightening up sipxbridge behavior
On Wed, Jun 16, 2010 at 12:29 PM, JOLY, ROBERT (ROBERT) <rj...@avaya.com> wrote: >> On Wed, Jun 16, 2010 at 11:07 AM, Martin Steinmann >> <mstei...@gmail.com> 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. > > Is it true to say that people that venture into using ITSPs that require ths strict protocol enforcement to be false should not expect the level of support you and your team have been providing up to now WRT interop issues? Me and my team ( which is a singleton set that includes me), will respond with indignation, alarm and despair should we see the flag in question be set to false. We will pretend to loose emails with attachments containing such snapshots and display other such rude and disagreeable behaviors. -- M. Ranganathan _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org 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/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org 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/
