Re: proposed charter 5 priority levels

In message <[email protected]>
John Rosenberg writes:

It's been mentioned that both RSVP and NSIS can carry both SIp priority and 
DSCP.
>  
> For the uninitiated (e.g. me!) would the use of either of these protocols 
> be used in a scenario where:
>  
> 1) an endpoint sent an INVITE to a call controller withtout RPH, but with 
> "dialed digits" that request a DSN precedence level (e.g. Flash);
>  
> 2) the call controller validated that the requested precedence level is 
> authorized;
>  
> 3) and the call controller then needs to inform the endpoint what specific 
> DSCP value (e.g. 41) to put in the bearer packets that the EP generates, 
> which value is based on a provisioned mapping resident in the call 
> controller between dsn precedence levels and DSCP values.
>  
> Thanks,
>  
> John


I'm not sure why the above example is special.  An RSVP PATH message
and RESV response (passed back from the IP egress) should precede any
SIP control traffic to avoid losing the control traffic.  You'd need
to do that once for all SIP traffic, not per flow.  The requested
bandwidth for the control traffic can be tiny.  An RSVP PATH message
and RESV response should precede any RTP data flow (bearer packets) to
avoid losing the voice payload.  The traffic must be policed to
conform to the parameters sent in RSVP and should be marked with a
fixed DSCP value appropriate for the service.

The SIP priority and DSCP value would be in the RSVP PATH message sent
before beginning to send RTP traffic (bearer packets).

For any sort of traffic which didn't involve a SIP setup (or any setup
protocol) you'd just send an RSVP PATH message and wait for the RESV
before sending traffic.  If SIP wasn't used then there is no need for
a SIP priority in the RSVP PATH message.

Am I missing something?  Perhaps an authorization or authentication
issue?

Curtis