Subject: Re: one-way media with 183 Session Progress

From: "Matt Squire" <[email-masked]>
Date: Fri, 26 Nov 1999 12:08:48 -0500

>
>From a different perspective, its very difficult (actually, impossible)
>to prevent users from sending best effort traffic to each other. If you
>are just providing best effort service, why do you care that users can
>send audio back before the call is complete? If you are providing
>transport level QoS, perhaps with diffserv, there won't be per-call (let
>alone per minute) billing, so again, who cares. In the case of per-call
>resource reservation, one can reserve resources even after the call is
>completed, so again this early media is not an issue. It is an issue if,
>and only if, you charge calls per minute, provided call by call resource
>reservation, and don't want to charge for calls until they are answered.
>This is more or less the DCS assumption. In this case, the right
>approach is not to prevent early media for announcements, but rather not
>provide it the enhanced QoS service that they will pay for once the call
>is answered.
>

I'm another person that doesn't see great benefits in the early media
response.  When and how to charge for calls seems like an accouting issue
that can be handled by the billing process well after call establishment.
The fact that some media is free and some is charged doesn't seem like it
should be a signalling issue.  The signalling can support this just as easy
by carrying appropriate authorization tokens and recording them for later
record processing.  

I would think that messages sourced by providers such as 'this number is no
longer in service' would require QoS.  Will companies really accept that
these messages, which are really part of their customer interface, reach
the customer as garbled junk?  
    "Hi, you've reached XYZ.COM.  We are !#$%^& to *#^% *#(because of #@%*!"
Can't imagine that going too well with corporate bigwigs.  

- Matt

---

From: Dean Willis <[email-masked]>
Date: Mon, 29 Nov 1999 20:59:44 -0600

Matt said
> Someone discussed QoS issues:
. . .
> Can't imagine that going too well with corporate bigwigs.

The early media response is one of the few workable solutions to getting the
"The number you have reached has been disconnected" messages sourced by a
terminating LEC switch back to a SIP client accessing PSTN through a
gateway. The terminating switch never actually sends an asnwer message back
to the gateway to get mapped into an ACK message, so the originating client
has to know to "listen" without ever receiving an ACK. From a phone company
perspective, this call was never completed. Once upon a time the switches
cut through two ways, but once people learned how to talk in-between the
rings or send phreak tones, we switched to a one-way cut through towards the
caller.

I believe this is a completely separable issue from controlling the billing
aspects of the call, and from establishing QoS around the call.

The issue with early media is that some people see a fraud opportunity
tantamount to tricking the phone company into playing the frauding message
INSTEAD of "the number you have reached" . . .

For example, in the PSTN case one might want any traffic between an IP
client and a gateway to have QoS. That's easy enough to do -- we just use
RSVP to set up the QoS like we would beween any other pair of hosts. The DCS
issues around call clipping pretty much don't occur for IP->PSTN calls,
because as the gateway is known BEFORE the digits are outpulsed to the
switch, QoS can be set up during the PSTN-side post-dial-delay.

Incoming PSTN->IP calls have a diffeent QoS problem, but they generally
don't need to worry about (and perhaps shouldn't even accept at the gateway)
early media signaling.

--
Dean