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

From: "Matt Squire" <[email-masked]>
Date: Tue, 30 Nov 1999 10:26:12 -0500

I really don't disagree with anything you say except the conclusion:)

As you state, the billing & QoS aspects are orthogonal to the goal of
getting the "number you have reached is out of order" messages back to the
SIP client.  The 183 I-D says

"   The only method in the current SIP specification that allows the
   called UA to playback media is to set up a full SIP session. In PSTN
   interworking situations (and likely in end-to-end SIP sessions) this
   will cause a billing relationship to be established between networks
   for the session.  This causes a problem when the reason for setting
   up the media session is to indicate a failure in the session setup.  "

This seems to indicate that billing is the major impetus for the special
handling of early media, and I don't think that's the case.  

If the QoS and billing are orthogonal, then the justification for this
seems to be that there's a slight reduction in the number of messages.  I
believe the diagrams in the I-D are slightly misleading, as the 183 has to
be sent reliably, so there are implicit acknowledgement going back that are
not shown in the pictures.  The message savings are not as shown in the
draft.  

People have raised issues that arise when INVITEs get forked, and you start
playing some early media like "the number has been disconnected" and then
you actually get an answer (200 OK) from another branch.  Certainly we can
just have each UA handle things as they see fit, but it demonstrates some
inconsistencies with these 'half-sessions.'  

Early media sessions are media sessions.  Changing the SIP behavior to
accomodate billing/QoS doesn't seem necessary.  The message savings seem
minimal.  Forking can lead to inconsistent behavior.  The message seems to
be easily bastardizable (is that a word?) to signal 2-way media or anything
else for that matter.  

I just thought SIP had a 3way handshake to establish a media flow for a
reason.  Getting rid of it in special cases worries me.  But I'm probably
in the minority, so I'll shut up about it now.  

- Matt

>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
>
>

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 30 Nov 1999 16:06:41 -0500

The problem that I see with early media is that there is not enough sematics
in the response to allow the user agent to make any decisions on what to do
with the call.  The user agent may not know whether the call is forked and other
responses may come back.  It does not know that whether the message to
be played is "number you have reached is out of order" or "please hold your call
is being transfered" (i.e. pending failure or setup).

I understand that the gateway may not have the sematics either (i.e. because it
is a simple gateway without signaling channels or it is blinded by a PSTN switch
which is not sending signaling).  Passing this all the way through the SIP
network
without a meaning in the early media message is only passing the problem off. The

UA is farthest from the source of the issue, how can you expect it to do
something
intelligent with it.  Enabling intelligence in the end point  is one of the
greatest
strengths of SIP.  I do not want to pass more noise and confusion to the end
user.
I want to filter it out.  Without any meaning to 183, the user agent will be
forced
to either make dumb decisions or overload and confuse the user with more
messages.

I can see two possible solutions:
1) As Matt has suggested only allow a complete session setup.
This does not provide the UA with any more information to make a decision.
It eliminates the decision.

2) Provide more meaningful response:
Minimally expand to 183 Session Pending and 184 Session Failing.  This way
the abiguity is not transmitted in SIP.  The meaning of 183 Session Pending
being that it is likely, but not guaranteed to proceed.  If a gateway is dumb
or blinded, it can default to 183.  Let's not make SIP blind as well.

Regards,
Dan

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 30 Nov 1999 16:33:38 -0500

Gee, I'm not conflicted by this early media stuff at all. Let's say instead
of an SDP in the 183 Session Progress the responder put a JPEG image, or a
HTML page saying "thank you for using AT&T". Only AI level intelligence on
the part of the initiating UA would give it enough information to know for
sure what it ought to do with the content. All I see the early media as
really meaning is "hey, listen to this while I'm trying to complete your
call".

I can even see uses for this outside of the PSTN gateway scenario. For
example, I might want to supply music or audio status along with a 182
QUEUED response - you know - "please stay on the line and an agent will be
with you as soon as possible".

The fact that this is the ONLY feedback sometimes available is an
unfortunate consequence of legacy PSTN technology. The alternative is to
implement full outbound-telemarketer tone/announcement recognition
capability in every PSTN gateway. Not a tradeoff I'd like to force on the
gateway vendors (since I "are" one :-) ).

One point I did make in my comments on the original 183 draft was that we
should keep the notion of early media, along with the QoS and Security
advisories separate from the particular 1xx response type. I think the
authors agreed to separate these things.

I have one question for Dan, interspersed in his note below:

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Daniel G.
> Petrie
> Sent: Tuesday, November 30, 1999 4:07 PM
> To: Matt Squire
> Cc: Dean Willis; [email-masked]
> Subject: Re: one-way media with 183 Session Progress
>
>
> Minimally expand to 183 Session Pending and 184 Session Failing.

Gee, if the gateway could tell that a session was failing it could probably
send back a final response directly and dispense with this stuff. As I point
out though, it isn't just failure notices that can come back in the audio.
It's anything that the PSTN stuffs in-band rather than sending back through
out-of-band signaling.

> This way

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 30 Nov 1999 21:54:40 +0000

> with you as soon as possible".

Well, Matts objection remains though: whether it would be "better" to
just establish a regular SIP connection right away, play the media, and
then possibly transfer the call later.

Anders

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 30 Nov 1999 17:00:24 -0500

> then possibly transfer the call later.
Then would you argue that the 182QUEUED response is unecessary as well?

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 30 Nov 1999 22:22:41 +0000

> Then would you argue that the 182QUEUED response is unecessary as well?

I didn't actually argue either for or against the 183, but no I
wouldn't. I don't think that's anywhere near the same issue, though. 

The main raison d'etre for the 183 is to request the establishment of a
session before the real session. In this sense it really modifies teh
flow of a SIP session setup.  The 182 Queued is much more innocent -
just an ordinary informational response with a bit of added semantics.
The caller can ignore it and noone would really know the difference.

Anders

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 30 Nov 1999 17:54:23 -0500

Dave:
I think that we are in agreement.  The problem is that the message may indicate
a failure, queued, ringing or some other status.

Sorry  I should clearify my concern.  I do not object to early
media.  Handling the early media is not the problem.  The problem is that
183 Session Progress as it stands gives no indication of the meaning of the
message.  It contains little more status than a 100.  Will the user hear a
happy message or a sad one?  ;-)

One comment below:
Cheers,
Dan

> gateway vendors (since I "are" one :-) ).

I am not suggesting that every gateway need be full featured.  A simple gateway
could always default to 180 Ringing or 182 Queued.  This signaling problem
exists
with the PSTN and/or Gateway interface.  I am suggesting that we leave it there,

not propogate it through SIP.  Over time I would hope that the PSTN signaling
and/or gateway capabilities will evolve to make it economically feasable to fix
this interface, transparently to the rest of the SIP world.