Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[e-mail]]
> Sent: Monday, May 03, 2010 5:43 PM
> To: Hadriel Kaplan
>
> - Appendix A: While I have no problem with simplifying the pattern, to
> enable less configuration errors and complaince with RFC3261. You
> bring back here the issue of automatically detecting provisioning
> mismatches by the PBX. Is this based on something you have seen in
> practice? Why would this be an issue at all? Even in the simplified
> case I don not think that an IP-PBX can conclude anything when it has
> knowledge about the full generated set of AOR's. It suffices to match
> each configured AOR with the patterns returned.

Yes, unfortunately it's been a real issue.  For example, there was a service outage just a couple weeks ago in a big carrier which impacted service for a bunch of Enterprise trunks.  Several things were configured incorrectly to make it become an actual outage of service for a bunch of Enterprise trunks, but the initial trigger which brought it down was the SSP thought the PBX owned a number and the PBX did not.  It caused an infinite loop, and due to poor configuration (and no throttles) several systems went to max utilization until humans stopped it.

So having a PBX just run a regex against the numbers it knows about is not enough - because that doesn't tell it what *additional* numbers the SSP thinks the PBX has which the PBX doesn't.  One could design a PBX to also use the regex against SIP Requests themselves, and decide that if the regex matches the Request's URI then it does own the username, and then return a 404 if it doesn't really have provisioning for that username.  But even that would get complicated fast.  These regex's are provisioned by people, and in my experience most people are really bad at creating _good_ regex patterns.  Unless we really need the complete flexibility of a regex pattern, I would recommend we avoid it.

-hadriel