Re: [Ieprep] proposed charter 5 priority levels

Curtis Villamizar <> Thu, 28 September 2006 05:21 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GSoLH-0001bx-9f; Thu, 28 Sep 2006 01:21:51 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GSoLF-0001bp-Rj for; Thu, 28 Sep 2006 01:21:49 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GSoLE-0007wh-Hq for; Thu, 28 Sep 2006 01:21:49 -0400
Received: from (localhost []) by (8.13.4/8.13.4) with ESMTP id k8S5T9NX002023; Thu, 28 Sep 2006 01:29:10 -0400 (EDT) (envelope-from
Message-Id: <>
To: John Rosenberg <>
Subject: Re: [Ieprep] proposed charter 5 priority levels
In-reply-to: Your message of "Wed, 27 Sep 2006 17:39:40 CDT." <>
Date: Thu, 28 Sep 2006 01:29:09 -0400
From: Curtis Villamizar <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

In message <>
John Rosenberg writes:

It's been mentioned that both RSVP and NSIS can carry both SIp priority and 
> 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


Ieprep mailing list