Subject: RE: [Sipping] sip-911, Preventing dialog termination

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 6 Mar 2002 17:14:05 -0500

Of course one might ask what "pre-emptive QoS" means in
a packet network!  Not a PHB I know of. Could be a higher DiffServ
priority than normal.

I say this only slightly tongue-in-cheek, because in the real world,
they really do want pre-emptive connections for emergency situations.
Even in our "actually works now, very big network reserved bandwidth
per call" ATM networks, you can't preempt a bearer.

Brian

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 4:54 PM
> To: Henry Sinnreich
> Cc: [email-masked]
> Subject: RE: [Sipping] sip-911, Preventing dialog termination
> 
> 
> I have to agree with Henry here.  There have been over 20 
> messages on this
> subject, most starting out with, "I think this is how 
> emergency services
> works..."
> 
> I was tempted to load my old BOC Notes on the LEC Network for 
> a definitive
> answer.  However, that would miss the point.  "What does the 
> PSTN do today?"
> is *not* the important question.  The important question is 
> "What do we need
> to do to offer equivalent OR BETTER service in the packet network?"
> 
> An example of this is the thought of using pre-emptive QoS on 
> call-back
> instead of "holding open the line".  [What does "holding open 
> the line" mean
> in a packet network, anyway?]
> 
> -----Original Message-----
> From: [email-masked] 
[mailto:[email-masked]]On Behalf Of
Henry Sinnreich
Sent: Wednesday, March 06, 2002 2:17 PM
To: 'David R. Oran'; 'Don Stanwyck'; [email-masked]
Subject: RE: [Sipping] sip-911, Preventing dialog termination

> Sounds like a job for...
> 	...superma...

There have been several proposals trying to make SIP emulate all the
PSTN functions and more.
A sure road to failure IMHO.
Thanks, Henry
[snip]

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

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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 07 Mar 2002 13:48:04 -0600

> I say this only slightly tongue-in-cheek,
I feel the same way...

>they really do want pre-emptive connections for 

I still don't know what a connection is on an IP network, unless RSVP is
deployed end-to-end. I will not hold my breath when/if this will happen
on the public Internet. As for private IP networks, I heard a rumor,
they are saving money too :-) , and bandwidth turns still out to be
cheaper than fancy QoS technology. Except maybe for wireless access, but
this does not help for end-to-end guarantees either.

And sorry to repeat, I'd rather get through without QoS and without
priority than not get through at all because some circuit-like
unavailability.

Henry

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Rosen, Brian
> Sent: Wednesday, March 06, 2002 4:14 PM
> To: [email-masked]'; Henry Sinnreich
> Cc: [email-masked]
> a packet network!  Not a PHB I know of. Could be a higher 
> DiffServ priority than normal.
> 
> I say this only slightly tongue-in-cheek, because in the real 
> world, they really do want pre-emptive connections for 
> emergency situations. Even in our "actually works now, very 
> big network reserved bandwidth per call" ATM networks, you 
> can't preempt a bearer.
> 
> Brian
> 
> There have been several proposals trying to make SIP emulate 
> all the PSTN functions and more. A sure road to failure IMHO. 
> Thanks, Henry [snip]
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Ken Carlberg <[email-masked]>
Date: Fri, 08 Mar 2002 10:02:11 +0000

> priority than not get through at all because some circuit-like

in general I would agree with you.  but there are vendors that are
and have been offering proprietary forms of call admission for VoIP
(typically by counting number of VoIP flows, or signaled calls).

as soon as one introduces call admission, then the chances exist for
call blocking.  and if your going to have that as opposed to across
the board degraded service, then some users will insist or require a
means of distinguishing traffic to get around that in some form.  
whether that involves preemption is a regulatory/policy issue.

automated preemption is not allowed on the US PSTN.  whether that
extends to the VoIP world in pure end-to-end ISP VoIP flows, i have
no clue and will let the lawyers battle that out.

and speaking of regulations and laws.  I see folks bring that up on
this list from time to time to make a point about whether a design
or technology should be allowed.  everyone should keep in mind that 
laws/regulation are relative to where one is.  while automated 
preemption is not allowed in the states for the PSTN, it may be allowed
elsewhere in other countries.  so please be careful when the word
law is used in an arguement.

cheers,

-ken