Hi,
I have one more question regarding this implementation. What happens if a
particular time falls in two different intervals of the recurrence - when
using CPL in SIP proxy?
<time dtstart="20050301T093000" duration="P40D" freq="yearly" interval="2"
bymonth="3,4">
This is not valid as the time in between "04-01 09:30:01" to "04-09
09:29:59" falls in two different intervals of recurrence (from March 1st to
next 40 days and from April 1st to next 40 days).
When implementing a SIP proxy, if the call falls in the specified interval
then we take some action. Even if the call falls in some other interval as
well, that does not affect the action to be performed.
Assume I want to tell that if the call comes from March 1st for next 40
days or April 1st to next 40 days - you proxy the call, otherwise reject
it. Actually this means if the call comes from March 1st till May 10th -
proxy the call, otherwise reject.
<time dtstart="20050301T093000" duration="P40D" freq="yearly" interval="2"
bymonth="3,4">
</proxy>
<otherwise>
<reject status="reject"/>
<time/>
In this scenario, how does it affect even the intervals overlap?
Intervals should not overlap, because to make sure that the call falls in
specified time, we have to do the calculation of candidate start time many
times and that affects the performance.
Apart from performance is there any other reason why the intervals should
not overlap - when implementing CPL in SIP proxy?
Regards,
Prashant
Jonathan Lennox
<[EMAIL PROTECTED]
ia.edu> To
[EMAIL PROTECTED]
01/23/2006 08:25 .com
PM cc
[email protected]
Subject
Re: [Sip-implementors] RFC 3880 -
CPL - 'duration' attribute value
On Monday, January 23 2006, "[EMAIL PROTECTED]" wrote
to "[email protected]" saying:
> Hi,
> I have a question regarding the interpretation of rxdurationry attribute
> value in 'timery node as mentioned in RFC 3880 (CPL).
> RFC 3880 - Section 4.4 - Time Switches
> "For a recurring interval, the "duration" parameter MUST be small
> enough such that subsequent intervals do not overlap."
> In the RFC, there is no further discussion on this statement. Please let
me
> know which of the following interpretation is correct.
The requirement is intended to ensure that by the algorithm given in the
appendix, there is only one possible candidate start time for any given
time, while still allowing maximum flexibility in the permitted recurrence
rules. Reducing this rule to a specific constraint is rather difficult,
which is why the rule is stated in this somewhat roundabout way.
> 1) 'duration' must be smaller than the 'freq * interval' value (byxxx is
> not considered)
> <time dtstart="20050301T093000" duration="P700D" freq="yearly"
interval="2"
> bymonth="3,4">
> Here 'duration' value should be smaller than (365 * 2 days)
This is not valid -- 2005-04-02 00:00:00 appears in two different intervals
of the recurrence.
> 2) 'duration' must be smaller than the minimum unit (taking byxxx into
> consideration)
> <time dtstart="20050301T093000" duration="P28D" freq="yearly"
interval="2"
> bymonth="3,4">
> Here 'duration' value should be smaller than 28 days (maximum difference
> between bymonth attribute values - assuming a month difference = 28 days)
This is a sufficient, but not necessary, constraint.
In particular, for this rule, P31D would be a valid duration, because March
has 31 days; and if you had a bymonth="3,9" parameter, P100D would be
valid.
However, for bymonth="2,3", P28D would be the maximum valid duration.
--
Jonathan Lennox
[EMAIL PROTECTED]
*********************** FSS-Private ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
