Subject: 183 vs 180, When and Where, a Proposal

From: Dean Willis <[email-masked]>
Date: Wed, 16 Feb 2000 17:12:47 -0600

Taichi Fu and I have been having a discussion on 18x provisional messages
with media that may be worth sharing. Here's what I think we agreed to.

For PSTN interworking, you really have to "listen" to the bearer channel to
figure out what's going on (see previous discussion on release codes). Note
that this is really quite different from a pure-IP scenario.

If we don't have PSTN interworking, then a 180 means that a user is being
alerted, and media on a 180 clearly indicates a custom message that can be
played to the caller. For example, a French user might want to play back the
distinctive French double-ring, and a Trekky might want to
play a clip of Lt. Uhuru saying "Captain, there is an incoming call".  We
might also want to include a text message for the audio-impaired device or
user, or present a visual notification such as a corporate logo.

On the other hand, many UASes (and proxies) MAY choose to ignore the media
on a 180. This can avoid very complex mixing scenarios in a forking
environment.

Devices MAY also choose to ignore the media on a 183, but this MUST be done
very carefully. Media on a 183 for PSTN interworking is far more critical
than that on a 180 -- it may provide the only useful information available
to the caller for determining the cause of a call failure. Think very
carefully before ignoring a 183.

We suggest that a straight IP system, especially a UAS, SHOULD send 180
(which MAY have media) when alerting a user. A PSTN gateway SHOULD send a
183 with media when "launching" a call onto the PSTN. Devices MAY decide to
ignore the media of a 180. Devices SHOULD present the media of a 183 to an
end user, and MUST deal with the results of not doing so.

A key point:

Some have argued that 183 also has uses outside of PSTN interworking,
whenever there is some status information describing a call which needs to
be presented "in band", but there has been no actual notification delivered
to a destination.

For example, consider a proxy (P) that implements a forking search. An
INVITE for "Joe" is delivered to P. P might, in parallel:
	1) respond with a 183 containing media in two parts.
		part 1 is an html object with
		text="Your call is being forwarded by Joe's Finder Service".
		part 2 is an SDP object describing a media stream with a spoken
		rendition of the same text
	2) send INVITES to all of the contacts Joe has on his contact list.

This is probably a BAD usage of 183 -- the status information, while useful
and entertaining, is not critical to the successful interworking of the
call. Its presence could obfuscate an upstream forking system, and would
provide no additional value to that system. This example SHOULD be
implemented using a 180, not a 183.

--
Dean

---

From: Taichi Fu <[email-masked]>
Date: Wed, 16 Feb 2000 18:59:33 -0800

Dean,

Thanks for the summary. I add a small note below the paragraph 6
from my understanding.

Regards,
-Taichi

>end user, and MUST deal with the results of not doing so.

That means, for SIP and PSTN interworking (a PSTN gateway converting
between SIP messages and SS7 messages):

(1) For a call from SIP to PSTN, a PSTN gateway SHOULD respond with 183 , and
(2) For a call from PSTN to SIP, a PSTN gateway SHOULD expect to receive 180.

An asymmetry.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2000 01:59:06 -0500

I'm not sure I like making this kind of distinction. Why not simply say
that a UAC always pay attention to media it is asked to receive via a
provisional response, and that pure IP UASs are advised not to send SDP
in provisional responses, but rather encode the data in the response
itself, via reason phrases or content. 

-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: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2000 10:33:57 -0500

> itself, via reason phrases or content.

Beyond this, I still have two major concerns/requirements:

- The caller needs to be able to express that it doesn't want audio.
Yes, it can ignore it, but the traffic may interfere with other on-going
communications.

- If this is an error condition, i.e., no call can ensue, when is the
UAS going to send a 4xx or 5xx? There is no right time, since it either
prematurely shuts off the explanation or it delays sequential searches
in proxies for very long time periods.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2000 11:44:38 -0500

> Yes, it can ignore it, but the traffic may interfere with other on-going

I'm not sure this is a NEED so much as something that might be a nice
feature. Actually
this seems something appropriate for caller preferences.

> in proxies for very long time periods.

My guess is that in practice, there will seldom be forking with gateways
involved. As such, reasonable behavior might be to send the audio,
potentially delaying the unlikely sequential search.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2000 11:44:49 -0500

> this seems something appropriate for caller preferences.

Agreed, or one can argue that it is a feature, described via Supported,
since not all end systems will even be able to accept voice ahead of 200
(e.g., they may only start the media tools after the 200 has been
received).

> potentially delaying the unlikely sequential search.

I'm not sure that's true. I get the voice announcement if a cell phone
(Sprint PCS) is not answering. If I route to both a home phone and cell
number, I don't want the announcement to delay ringing the other phone.

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Feb 2000 13:39:14 -0600

Well, some marketing folks I know got all gooey over custom ringback, which
I see implemented as 180 with SDP pointing to a streaming audio source. I
suppose one could provide this with a back-to-back UA and a transfer
operation, but the signaling semantics would be much more annoying if the
UAC proved to be a gateway.

--
dean

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Thursday, February 17, 2000 12:59 AM
> To: Dean Willis
> Cc: IETF SIP; Taichi Fu
> Subject: Re: 183 vs 180, When and Where, a Proposal
>
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Feb 2000 13:39:16 -0600

Thanks for the clarification. That's what I meant.

--
Dean

Taichi Fu said:
> [mailto:[email-masked]]On Behalf Of Taichi Fu
> Sent: Wednesday, February 16, 2000 9:00 PM
> To: Dean Willis
> Cc: IETF SIP
> >                 part 2 is an SDP object describing a media
> stream with a
> > spoken

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Feb 2000 13:49:21 -0600

> (e.g., they may only start the media tools after the 200 has been

Then they're going to have a hard time making calls to the PSTN, where
"early media" is a fact of life.

> > potentially delaying the unlikely sequential search.

The UAS sends a 4xx on teardown-with-cause from the PSTN side. This is AFTER
the message has been played. Can't do it sooner and still work.

> number, I don't want the announcement to delay ringing the other phone.

It may be necessary to consider things like a "forking proxy" that can fork,
absorb the 183(s), record the media attached to it(them), notify the caller,
then play the media back on demand. This lets a user do things like "Hmm,
that call failed, I wonder why. Oh, my message light is blinking, there must
be a telco message from that call." I call this "thinking carefully about
ignoring the provisional media". Save this, it's "prior art".

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2000 15:32:45 -0500

> "early media" is a fact of life.

Not for devices like autodialers. They want to get off the line as
quickly as possible, however useful the phonelady spiel.

> the message has been played. Can't do it sooner and still work.

The problem is that AFTER is ill-defined. As far as I know, the "The
number you have dialed has been changed. The new number is ..." repeats
indefinitely or at least a very long time.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Feb 2000 10:33:13 -0500

Thats fine. My suggestion was that if possible, to encode reasons in
responses rather than use provisional media. But, that UACs still pay
attention to it if provisional media is sent, for something like
distinctive ringing.

-Jonathan R.

Dean Willis wrote:
> > stream with a spoken

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Feb 2000 10:34:18 -0500

> ignoring the provisional media". Save this, it's "prior art".

You can certainly do this, but I definitely don't want to mandate this
kind of behavior in a normal proxy. 

-Jonathan R.