Subject: one-way media with 183 Session Progress

From: "Schroeder, Tim" <[email-masked]>
Date: Mon, 22 Nov 1999 16:49:55 -0600

Regarding the possibility of setting up a media stream with the 183 Session
Progress message ...

I can see why this is nice, though I don't understand (today) why this is
necessary.  And it does seem to have similar potential for abuse as the INFO
method does.  Agreed, it sounds helpful to be able to send back the status
of the call completion.  But what (if anything) stops a called party's UAS
from using that one-way media stream to read back the value of a caller's
stock portfolio?  Or connecting it to a microphone, while simultaneously
initiating a new call back to the original caller, in order to get a second
one-way media stream?  There are certainly services where a one-way stream
is all that is necessary, and with two one-way streams in opposite direction
I can do nearly anything.

Again, it would seem that the solution is to charge someone for the one-way
stream -- probably the called party (who is setting it up).  But again that
results in charging for uncompleted calls.  

Even without the media stream, repeated 183 Session Progress message seems
like they could be used to transfer some (maybe not significant) information
prior to call completion.

In a PSTN interworking scenario involving both local and LD carriers, it
seems like it would be possible to construct a scenario where the LD carrier
ends up carrying a one-way media stream for a significant length of time,
but is never paid for that service, because the call is never completed with
an ANM.

Tim Schroeder

This e-mail and any files transmitted with it are the property of SBC, are
confidential, and are intended solely for the use of the individual or
entity to whom this e-mail is addressed. If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received this
message in error, please notify the sender at [email-masked] and
delete this message immediately from your computer. Any other use,
retention, dissemination, forwarding, printing, or copying of this e-mail is
strictly prohibited.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Nov 1999 18:12:59 -0500

> I can do nearly anything.

You should read the DCS drafts, as they tackle these issues from one
perspective.

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.

> prior to call completion.

IP allows people to send data. Once I receive an INVITE, I have your IP
address. I can send you instant messages, email, web pages, ftp data
to/from you, and so on anyway.

-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