Subject: [Sipping] Comments on Reason Header for Preemption Events

From: [email-masked]
Date: Sat, 22 Nov 2003 08:55:04 EST

Following the discussion in the meeting, I have the following comments on:

draft-polk-sipping-reason-header-for-preemption-00

The current Reason Header provides for coding either a SIP response code or a 
Q.850 ISDN cause code. Since the Q.850 codes are sufficient to support MLPP 
in the existing network, they shoud be sufficient in a SIP controlled network, 
so I am not convinced of the need for this extension.

If this is to published as an Informational RFC, since SIP is to do the 
actual protocol work, Section 4 needs to be deleted.

If not deleted, I understand that it was agreed in the meeting to change 
"preempted_network" to "preempted_resource". This would also require an extensive 
rewrite of section 3, since it specifically describes "Network Preemption".

From the point of view of the "Assured Service" I have been documenting in 
various drafts, the following requirement related to these new Reason Header 
values is the following:

When a user's call (session) is preempted due to either a resource preemption 
(in the network) or an access preemption at the other end of the call 
(session), it MUST NOT be possible for that preempted user to know which of these two 
events occurred.

(In other words, the final sentence in Section 2.0 of the draft is incorrect.)

The result of this requirement is that the reason sent back to UA1 in Figure 
4 cannot be "preempted_UA". It must be "preempted_resource", where it is 
intentionally obscure about which resource was preempted (as shown in Figure 1). 
"Preempted_UA" would only be sent to the UA that is being preempted for a new 
call (UA2 in Figure 4) if 3PCC or a proxy were involved.

Mike Pierce

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 23 Nov 2003 09:35:55 -0500

--On Saturday, November 22, 2003 8:55 AM -0500 [email-masked] wrote:

> The current Reason Header provides for coding either a SIP response code
> or a Q.850 ISDN cause code. Since the Q.850 codes are sufficient to
> support MLPP in the existing network, they shoud be sufficient in a SIP
> controlled network, so I am not convinced of the need for this extension.
>
I might be willing to buy your conclusion, but your logic escapes me. Just 
because the methods for preempting space at the water trough for pony 
express horses is demonstrably adequate for the western mail system, does 
not mean they are adequate for preempting traffic flow on today's roads for 
ambulances.

> "preempted_network" to "preempted_resource". This would also require an
> extensive rewrite of section 3, since it specifically describes "Network
> Preemption".
>
You seem to have a very narrow and politicized view of what constitutes a 
"network". What precisely concerns you with the use of this term?

> From the point of view of the "Assured Service" I have been documenting
> in various drafts, the following requirement related to these new Reason
> Header values is the following:
>
> When a user's call (session) is preempted due to either a resource
> preemption (in the network) or an access preemption at the other end of
> the call (session), it MUST NOT be possible for that preempted user to
> know which of these two events occurred.
>
Huh? Why? I think you're still living in TDM-land, or at least in the land 
with some kind of regulatory hard boundary between "the network" and "the 
user" where somehow letting the user know which happened opens up some kind 
of opportunity for abuse, or a wedge through which the lawyers enter. Could 
you give some justification in the environment of the Internet for 
introducing this kind of information hiding?

> The result of this requirement is that the reason sent back to UA1 in
> Figure 4 cannot be "preempted_UA". It must be "preempted_resource", where
> it is intentionally obscure about which resource was preempted (as shown
> in Figure 1). "Preempted_UA" would only be sent to the UA that is being
> preempted for a new call (UA2 in Figure 4) if 3PCC or a proxy were
> involved.
>
I disagree with all of the above, but my disagreement may of course be 
based on misunderstanding or poor logic, so please convince me that I'm 
wrong here.

Dave.

> Mike Pierce

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]