Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08

[Richard Barnes <[e-mail]>]

Inline.  Areas of agreement snipped.


On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <[e-mail]>wrote:

> To be clear on this, the ambiguity here is with regard to the <except
>> domain="..."> case.  In the <one id="..."> case, you just do Tel URI
>> comparison.
>>
>> Thinking on this a little more, it looks like your use of the "domain"
>> parameter actually breaks with RFC 4745.  According to RFC 4745, there must
>> be an exact match between the "domain" value provided by the using protocol
>> and the value in the "domain" parameter.  I can't think of a way that this
>> document could define a way to extract a domain from a telephone number
>> that would meet the semantic you seem to be intending.
>>
>> So it seems like you need to do one of the following:
>> 1. Define a rule for how you compute a domain value from a tel: URI.
>> 2. Define a new element for use under <many> (since <except> lacks an
>> extension point)
>> 3. Drop support for excluding phone numbers by domain (you just have to
>> enumerate the exceptions individually)
>>
>>
> [CS] If we opt for Option 1, can we do the following:
>
> a. assume E.164 numbers always start with + sign, so we can use the digits
> after the + sign (after removing any visual separaters, as in the Tel URL
> comparison rules) as the presumed domain value.
> b. for local numbers (numbers that do not start with +), the
> "phone-context" contains the domain value.
>

Are you sure that gives you the expressiveness you want?  It doesn't allow
you to exclude based on an arbitrary prefix.  For example, <except
domain="+1212"> would not match the URI "tel:[phone]", because the
"domain" value for that URI would be "12125551212".

It seems like (2) is the option that's most likely to give you what you
want.  Suggest defining something like a "<except-tel>" element, so that
you could say something like <except-tel prefix="+1212">.


To be clear, the concern here isn't about a policy that combines two
>> actions in the same rule.  The concern is when two rules match the same
>> call, in which case both actions must be applied.
>>
>> For example suppose you have the following rule set:
>> RULE 1: Reject all calls from example.com
>> -- Conditions: <from><identity><many domain="example.com
>> "/></identity></from>
>> -- Actions: <accept alt-action="reject"><rate>0</rate></accept>
>> RULE 2: Redirect all calls from [e-mail]
>> -- Conditions: <from><identity><one id="sip:[e-mail]
>> "/></identity></from>
>> -- Actions: <accept alt-action="redirect" alt-target="sip:[e-mail]
>> "><rate>0</rate></accept>
>>
>> It doesn't seem like there's a sensible way to combine those rules.  In
>> principle, it seems like the simplest thing would be to say that a policy
>> MUST NOT specify two rules that could apply to the same SIP message.  Would
>> people feel comfortable that you could efficiently check this exclusivity?
>>  It does scale as the square of the number of rules.
>>
>>
> [CS] Very good point. We propose an easy "the first-match rule", i.e.,
> the call is handled based on the first rule that matches. What do you
> think?
>

That seems pretty sensible.  I think the way to state this is add some text
to Section 7.4 defining the Combining Rule (to use the phrase from RFC
4745) for the <accept> action.

Thanks,
--Richard