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/

Reply via email to