Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (3) Tue, 16 November 2004 14:50 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA03855 for <>; Tue, 16 Nov 2004 09:50:21 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CU4hE-00076e-Ay for; Tue, 16 Nov 2004 09:52:40 -0500
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CU4Yu-0006N0-7o; Tue, 16 Nov 2004 09:44:04 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CU4PV-0004Sh-VV for; Tue, 16 Nov 2004 09:34:22 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA02592 for <>; Tue, 16 Nov 2004 09:34:20 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CU4Rj-0006i7-9M for; Tue, 16 Nov 2004 09:36:39 -0500
Received: from by (mail_out_v37_r3.8.) id d.b8.66a7d290 (4238); Tue, 16 Nov 2004 09:33:45 -0500 (EST)
Message-ID: <>
Date: Tue, 16 Nov 2004 09:33:45 EST
Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (3)
MIME-Version: 1.0
X-Mailer: 6.0 for Windows XP sub 10500
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0964403507=="
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, writes:

> 3. With "preferential treatment" of messages based on R-P content, 
> should not scenarios be considered and listed in which a lower priority 
> message  would need to be handled before a higher priority message?  My 
> example: it would be wise to handle a BYE message with dsn.routine 
> before an INVITE with dsn.flash-override...  At least in certain 
> situations, say when the BYE is sent as a result of a preemption event 
> (which the Reason header should likely indicate).
> ---- Certainly something to consider, especially for DSN.

Yes, this is an interesting idea. However, as in the SS7 world, it is a bad 
idea to intentionally do things that might change the sequence of messages. In 
the example you mention, I would expect that some entity controlling 
preemption would simply send the BYE for the routine call before it sends the INVITE 
for the new flash-override call. If two different entities send these two 
messages, it is a virtually non-existent case that both messages would happen to be 
in the same queue waiting to be sent to even allow some entity to reorder them.

What sometimes confuses this issue is what is done in SS7 (see 
draft-pierce-tsvwg-pref-treat-examples-01). SS7 has a "congestion priority level" associated 
with each signaling message, which is really a discard priority. Some 
(including me) have been confused into thinking that it changed the order to 
transmission, by sending the higher priority messages first. It does not. For the SS7 
messages corresponding to BYE and INVITE and for routine and high priority 
calls, the congestion priority leveI defined for SS7 (and the corresponding SIP 
message) are as follows:

IAM (INVITE) (routine)  0
IAM (INVITE  (priority) 1 or 2
REL (BYE)    (all)      1

This means that, if the signaling system 7 network gets congested, the new 
call setup messages (IAM) for routine calls are the first to be discarded (which 
helps to prevent catastrophic overload).

The draft mentioned about only raised this issue as something to consider to 
provide "preferential treatment" for the various signaling messages, as you 
suggested in your question. But I would only see it as being similar to the SS7 
implementation - determining which messages to discard when you have to 
discard something, not changing the order. It could use AF behavior with 3 drop 

My initial belief is that such a mechanism is not needed, presuming that 
other techniques can ensure the the SIP signaling traffic will never get to the 
congestion point. If not, then I think we need to consider such a mechanism, but 
it's not something that needs to be described in the R-P header draft.

Mike Pierce

Sip mailing list
This list is for NEW development of the core SIP Protocol
Use for questions on current sip
Use for new developments on the application of sip