Subject: Re: Prioritization limitation question

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 5 Jan 2000 13:44:15 -0600 (CST)

>I agree we will have to have a fully worked out proposal
>not just an additional level or two.
>
>Do you believe that the existing SIP priority field should be 
>reused (essentially having a way to state that the priority is 
>mandatory, not advisory), or add a whole new field?
>I'd rather the former.

I'd propose using different headers, simply because I don't
like the philosophy of overloading existing headers in extensions
to mean semanticaly different things. I propose that your callflow
might look like:

* I launch a normal invite to Joe:

  INVITE sip:[email-masked] SIP/2.0
  To: <sip:[email-masked]>
  From: <sip:[email-masked]>;tag=13948753987
  Call-Id: [email-masked]
  CSeq: 1 INVITE
  Via: SIP/2.0/UDP ws0985.ericsson.com

* His MLPP-capable device responds with a busy, and an
  indication that he supports MLPP (along with a version,
  in case the semantics need updating in the future):

  SIP/2.0 486 Busy Here
  To: <sip:[email-masked]>;tag=a872-27bc-287e-7d7f
  From: <sip:[email-masked]>;tag=13948753987
  Call-Id: [email-masked]
  CSeq: 1 INVITE
  MLPP-Version: 1

* Seeing that his phone supports a version of MLPP that my phone is
  capable of, my phone gives me the option of invoking the CCBS service.
  I activate it with a level of immediate (2). The phone re-launches
  my INVITE request to Joe's phone:

  INVITE sip:[email-masked] SIP/2.0
  To: <sip:[email-masked]>
  From: <sip:[email-masked]>;tag=13948753987
  Call-Id: [email-masked]
  CSeq: 2 INVITE
  Via: SIP/2.0/UDP ws0985.ericsson.com
  MLPP-Version: 1
  MLPP-Priority: 2

* Joe's phone "does the right thing" and takes my call:

  SIP/2.0 200 Okay
  To: <sip:[email-masked]>;tag=7f27-237e-ab71-0277
  From: <sip:[email-masked]>;tag=13948753987
  Call-Id: [email-masked]
  CSeq: 2 INVITE

Before soneone starts a discussion on the fact that
the INVITE must be launched twice: note that this is the
same way this service is handled in the PSTN currently. A
call attempt gets a busy indication with a CCBS flag set;
the call attempt is then re-launched with MLPP. Presumably,
this is done for a reason. The above solution should
satisfy the same requirements as the PSTN version of this
service.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Jan 2000 18:08:51 -0500

Rather than using this MLPP-Version thing to indicate support for CCBS,
I'd rather use the more generic Supported/Require mechanism (a draft on
this is pending within the next few days). So,

C->S INVITE

S->C 421 Feature Available
Require: com.cisco.mlpp

C->S INVITE
Supported: com.cisco.mlpp
MLPP: 2;version=1

S->C 200 OK

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 5 Jan 2000 17:50:02 -0600 (CST)

>Supported: com.cisco.mlpp

It sounds like you're adding yet another round trip:
the first to agree on the feature, the second to try
an invite (which gets a "busy" response), and the third
to invoke the feature (am I misreading something here?)

Keep in mind that MLPP is relevant only when the far side
returns an indication like "busy." Only *after* the calling 
party is notified that the far side is busy does he make a 
decision that he wants to break in on the call.

Also, in PSTN interoperation scenarios, the gateway won't
know that you can break in on the called party until the busy
indication arrives (since we're just pumping the call back
into the network and don't necessarily know the capability
of the end office to which the subscriber is physically 
connected) -- so negotiation of the feature cannot occur before 
an attempt is made to reach the called party.

If we're going to go out of our way to borrow a service from
ISUP, we'd be exceedingly foolish not to make them able to
interoperate.

---

From: Bob Bell <[email-masked]>
Date: Thu, 06 Jan 2000 08:42:38 -0700

Gentlemen -

There is another aspect of MLPP which is being ignored here. That is that I 
don't want to talk to you, I just need the bandwidth your communications is 
consuming over a WAN link of limited bandwidth. So, I (or a proxy which has 
a better network view that I do) needs to tell you that you must terminate 
the call. Thus, there is no opportunity for me to present an INVITE to you 
and for you to return a Busy indication.

Bob

>ISUP, we'd be exceedingly foolish not to make them able to

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jan 2000 12:11:17 -0500

This is a much different service. As the SIP path and media path are
different (and, in fact, may flow through completely different service
providers), there is really no way for this to be handled at the SIP
layer. A proxy can't know to tear down someone elses call if bandwidth
were available. Even the UA probably can't know that his call is
consuming bandwidth that is preventing some other call from being made.

Rather, if the *service* we need is that some generals call gets enough
bandwidth, overriding some private, this is best handled by some kind of
diffserv or rsvp operation.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jan 2000 12:18:52 -0500

> to invoke the feature (am I misreading something here?)

I wasn't suggesting that. I was suggesting that if the far side is busy,
and has this CCBS thing, it returns a 421 feature available with this 
Require header.

Anyway, based on Bob's mail, it may not matter.

-Jonathan R.

---

From: Bob Bell <[email-masked]>
Date: Thu, 06 Jan 2000 12:13:41 -0700

Jonathan -

I understand that this is a different aspect of the problem. It does bear 
on SIP in that if a lower priority call is "preempted", there is supposed 
to be a signal given to the end stations indicating that they have been or 
are being preempted. That signal would need to be SIP. How and where it is 
originated is a totally different issue and one I don't currently know how 
to solve. There would need to be some form of feedback from RSVP or 
DIFFSERV or ???? to allow for that interaction.

Bob Bell

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)

---

From: Bob Bell <[email-masked]>
Date: Thu, 06 Jan 2000 12:15:35 -0700

Jonathan -

This form, where I need to preempt a call that you have currently active so 
that I can talk to you is also a valid case. Don't abandon this part just 
because the other part also exists.

Bob

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 06 Jan 2000 15:10:52 -0600

Bob, I will give it a try.
A QoS enabled SIP client, like a SIP phone would actually have an RSVP
client as well. If bandwidth is preempted during a QoS assured call, it is
up to the client to react and advise the user with a notice "Lost QoS for
this call" and give the user the choice to continue the call with best
effort service or to hang up. Since QoS assured calls will probably command
some premium rates, the knowledgeable user may not be completely unhappy not
to be charged for QoS minutes any more. It will also allow for a more
graceful termination of the call by the user himself/herself instead of
being just cut off in the middle of a conversation. Or do I understand the
problem right?

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bob Bell
Sent: Thursday, January 06, 2000 1:14 PM
To: Jonathan Rosenberg
Cc: Adam B. Roach; Rosen Brian; [email-masked]
Subject: Re: Prioritization limitation question

Jonathan -

Bob Bell

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jan 2000 16:30:18 -0500

The first problem is that there is no way I know of in RSVP for one
reservation to preempt another, and for notification of preemption to be
delivered (there has been some work on MPLS extensions to RSVP which
allow replacement, but I don't know if thats useful for this
application). 

Even if it did, I'm not really sure it matters. This isn't a circuit
network; pre-emption does not imply a one to one replacement of one
circuit with another. One could add priorities to an rsvp reservation so
it always succeeds; all this means is that the loss rate of existing
connections is increased if there really wasn't enough bandwidth for the
new one. You can rely on human response to that to hang up if it gets
really bad. In most cases, I suspect a WAN connection that supports any
kind of data traffic at all will have sufficient resources so that these
high priority reservations won't impact one drop existing calls.
Furthermore, adaptive mechanisms that use FEC or redundanct codecs will
allow performance to be probably not bad for loss rates that are quite
high.

-Jonathan R.

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 06 Jan 2000 16:05:04 -0600

An access network, such as an ISP or intranet may want to manage their
premium rate QoS pool from a policy server talking COPS to the edge router
(that enforces the policy) connecting to the IP backbone. If the policy
server is smart enough to understand priorities, it can de-install the QoS
policy for some unfortunate lower level callers and install precious QoS for
the higher priority application, SIP telephony or anything else. Maybe a
corporate video announcement from the president, or an emergency. The
initial draft for such a model is
http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-o
sp-00.txt
though we are planning on an improved version soon.

Interested to know if this model for QoS management from a policy server is
broken or OK, so your comments are appreciated. If the model holds, than we
have an answer to Bob's problem.

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan
Rosenberg
Sent: Thursday, January 06, 2000 3:30 PM
To: Bob Bell
Cc: Adam B. Roach; Rosen Brian; [email-masked]
Subject: Re: Prioritization limitation question

-Jonathan R.

Bob Bell wrote:
> > > >Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho,
MS
> > L-04