RE: [Sip] S-S-L mode in RPH for ets and wps (#5)

["James M. Polk" <[e-mail]>]

comments in-line

I shortened the subject line BTW

At 02:13 PM 11/8/2004 -0500, Janet P Gunn wrote:
>James said:
>___
>
> > > 5 Precedence (queueing) is generally the means of providing priority,
>but
> > > exemption from network management controls, for instance call admission
> > > within an IP domain, when a "regular" call would not be admitted, is
>also
> > > needed.  Pre-emption is not used.  (semi-strict "plus more")
>
>I do not understand what you have written above, can you rephrase please?
>___
>
>OK. I'll try again (and I combined two different cases, which didn't help
>the clarity).
>
>Section 7 says
>       "The ets and wps namespaces operate with preferential treatment but
>    without preemption.  These namespaces operate under a policy of
>    provide preferential treatment to higher relative priority requests
>    instead of processing lower relative priority requests.  Messages
>    are not preempted, or deleted, except under extreme loads in which
>    all available processing is taken up with higher priority messages.
>
>    An example of this is at a IP/PSTN gateway with all of the PSTN side
>    circuits utilized.  In strict mode one of the lower priority
>    circuits would be freed using preemption.  In semi-strict mode, the
>    SIP request May be granted access to the next available circuit
>    based on this header's presence in the authorized message,
>    regardless of how many other "regular" requests are received at that
>    gateway."
>
>First, is that "May" supposed to be "MAY" or "may"?

MAY

I mistyped it

Now, you could contract that this is a MUST within whoever you contract 
with for IP carrier.  This is a big difference that should be pointed out 
here, the difference between market requirements and protocol requirements. 
A doc can say "MAY", but a customer can demand that aspect be a MUST in 
their network. If the doc says MUST (or even SHOULD in most cases), 
equipment vendors really don't have a choice but to code this feature into 
their products, even if 1 or more customers do not use it. This is a 
marketing decision.


>But more significantly, the desired behavior at the PSTN gateway is more
>complicated than what you describe;

I could write a book about exactly how many behaviors are to be.... but I 
may have oversimplified things here.


>-At an IP/PSTN gateway with all of the PSTN side circuits utilized, not
>only would the request with the appropriate RPH be granted "the next
>available circuit" but if several requests with the appropriate RPH arrive,
>they would be queued for the next several circuits to become available.

true, I didn't get into the multiple request scenario - I could add this 
here, but do not want to account for every permutation for each behavior 
every time. All documents would be very long in this philosophy.


>- At an IP/PSTN gateway, "restrictive network management controls" may be
>active, even if  not all PSTN side circuits are utilized.  (An example of
>a "restrictive network management control" is "call gapping" in which only
>one call every x seconds is accepted.  "Call gapping" is usually made
>active as a response to overall network congestion, a bit like ECN in an IP
>network).  If restrictive network management controls are active, a request
>with the appropriate RPH would be granted an available circuit, even if
>less than x seconds had passed since the last call was admitted.

I will restate to "all available circuits are utilized" to account for 
this. but do not want to get into restrictive mgmt control.


>- At an IP/PSTN gateway, if the request has the appropriate RPH, certain
>parameters (CPC and/or Precedence) would be set in the ISUP IAM.

this isn't a SIP issue, this is a translation issue that the GW vendor is 
to deal with.


>I don't see anything in the RPH ID that prevents this "additional"
>functionality, so this comment doesn't necessarily mean anything needs to
>change.  It was just that the current text is a little misleading in that
>it seems to imply that "access to the next available circuit" is all that
>is intended.

I think I cleaned up the text appropriately to your above points


>Janet
>
>----------------------------------------------------------------------------------------
>
>This is a PRIVATE message. If you are not the intended recipient, please
>delete without copying and kindly advise us by e-mail of the mistake in
>delivery. NOTE: Regardless of content, this e-mail shall not operate to
>bind CSC to any order or other contract unless pursuant to explicit written
>agreement or government initiative expressly permitting the use of e-mail
>for such purpose.
>----------------------------------------------------------------------------------------


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip