Subject: Re: When to send 183?

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 10 Feb 2000 09:28:47 -0600 (CST)

>In "draft-ietf-sip-183-00.txt", one of the sections reads as follows:
>
>"5.11.6. Callee Needs Early Media
>
>   When the called UA receives an(d) INVITE message that results in the
>   need to report on the status of the media setup through a media
>   stream, the called UA has the option to send a 183 message with a
>   session description to the calling UA."
>
>If the called UA happens to be a PSTN gateway, on what basis will it
>determine
>if there is a need to report on the status of the media setup (and
>hence, send a
>183, as opposed to sending the usual 180 ringing)?

You would use the 183 only if you:

a) Are able to determine that the audio being generated
   is certainly *not* ringing (e.g. "comfort tone" or
   "pay tone" as defined in E.18x), or

b) Are unable to definitively determine that alerting
   is occuring. This really should only happen with older
   CAS protocols. ISUP and ISDN have sufficient information
   to determine what is happening on the far end.

You can also use 183 if you are able to determine that an error
has occured, but that there is a tone or announcement accompanying
it (e.g. an ACM with a cause code present), you can send a 183
to set up the media for the announcement (ideally with the
announcement text as the text string), wait for a timer (on the 
order of ~30 seconds), and then send an appropriate SIP error 
message.

-- 
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: "Daniel G. Petrie" <[email-masked]>
Date: Thu, 10 Feb 2000 11:22:42 -0500

I agree with a) and b).

Forgive me as I have not kept up with the lastest on the 183
draft, but I would argue that if it is known that an error has
occured, that a 3xx, 4xx or 5xx code should be used.  Not telling the
UA of a known error, prevents it from handling the call in a means
best suited for the user.  If we need a two stage error to frame
the error media stream then, I would argue that we need a 18x
status that means an error is about to occur.

183 should only be used when it is impossible to tell the out come
of the call setup.  Using 183 when a known error has occured
blinds the UA unnecessarily.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Feb 2000 11:59:40 -0500

"Adam B. Roach" wrote:

> order of ~30 seconds), and then send an appropriate SIP error

There seem to be two somewhat separate cases:

- progress tones and announcements

- failure tones and announcements

In either case, the receiver may or may not care to hear them. (I don't
think current telemarketing systems are smart enough to have a voice
recognition system translate "The number you have dialed is no longer in
service. The new number is ..." into a database update...)

Particularly for failure indications, it would seem to be preferable to
simply say "give me the error code (even if it's just "failure for
unknown reason") and spare me the phone lady". I suppose one way to
solve this is to only include the "Supported" header for this feature
for non-robots.

I believe we had discussed as one alternative for the failure case a 20x
variation that says "you haven't reached the real person, but here's a
robot; BYE it if you'd rather not talk to one". A potential problem with
the current solution is that some messages are infinite-length
(repeating), say for number change messages. You don't just want to cut
off after 30 seconds, since I may need to run to fetch a pencil... 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 10 Feb 2000 11:57:12 -0600 (CST)

>blinds the UA unnecessarily.

But it's not a violation of the protocol. It's an implementation
issue. You can design your gateways as you see fit, for the purposes
of your customers. You can even make it configurable or based on
the particular call (e.g. send pre-failure media only for queries
from hosts who have sent me ISUP bodies).

Addressing the utility of pre-failure media: if the call is going 
from PSTN to PSTN with a SIP transit network (possibly providing 
services), the *media* indication of failure is very important.
I don't want a reorder tone when some machine off in the network 
is helpfully announcing my friend's new phone number. On the other
hand, If you're terminating at a native client, they'll want an error 
code instead (or possibly a 301, as in the above case).

My intention was not to tell anyone how the protocol must be used;
I meant to inform what it allows you to do. I assume that anyone
designing a PSTN gateway has done enough analysis to determine what
behavior is appropriate to meet the requirements of their particular
customers.

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 10 Feb 2000 12:09:42 -0600 (CST)

>service. The new number is ..." into a database update...)

They wouldn't necessarily need to. For ISUP, the ACM message in these 
circumstances contains a release code of 22 (Number Changed), along
with a new number. Whether current telemarketing systems utilize this 
information is another issue altogether -- one that I have no knowledge 
about.

Getting back on topic...

It seems a bit odd that a caller wouldn't want to know about
the progress tones (e.g. ringing, "your call has been queued,"
"your call is being forwarded to a phone outside company premises"
[which I beleive may be a legal requirement in some circumstances]).

I agree that native clients may not want to know about failure 
announcements (and certainly wouldn't want to hear failure tones).

However, as I argued in my previous message, there is a definite
utility to transiting this information between gateways under
certain circumstances. The protocol and 183 extension don't
currently prohibit this behavior; doing so would cripple the 
extension for a whole class of PSTN interoperation issues.

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 Feb 2000 00:10:08 -0600

>    to determine what is happening on the far end.

I would argue that a PSTN gateway which is talking to a native UAS (rather
than another ss7 gateway) should ALWAYS return 183 upon entering a
call-pending state (such as when receiving an ACM from an egress switch).
This behavior is required for:

1) Specialized ringing tones, and
2) Network announcements, such as "The number you have reached has been
disconnected".

The early media session MUST be available BEFORE the announcement is played.
You can't wait for audio detection before setting it up, or the announcement
would be clipped.

In fact, I would go so far as to say that a gateway that does NOT implement
this feature is pretty close to useless for IP-PSTN call routing. Such a
gateway would only be useful for the PSTN-IP-PSTN role being pursued by
alternate-route carriers where SS7 release codes are tunneled back to the
originating switch (and I'm frankly not sure it even works then). This needs
to be fixed in the SIP-T work if we ever want to talk to REAL internet
devices, instead of just tunnelling calls between gateways. I don't believe
any real telco would buy an IP-PSTN gateway that doesn't support 183 with
early media -- they just wouldn't be useful.

One might argue that a UAS which knows it is placing a call thru an IP-PSTN
gateway might want to state a requirement for 183 support in its initial
INVITE. This approach would allow a gateway to decide whether to 183 based
on the initiating INVITE, thereby allowing a gateway to server pstn-ip-pstn
and ip-pstn transparently.

One might also wonder how a forking proy would deal with 183 messages
relating to a call that has been forked.

--
Dean

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 11 Feb 2000 09:16:57 -0600 (CST)

>call-pending state (such as when receiving an ACM from an egress switch).

I would argue that this is only appropriate when no other 1xx code
will adequately describe the state. 

>1) Specialized ringing tones, and

If you're providing a specialized ring tone, I would argue that you
should send a 180 *with an SDP body* to indicate that you're providing 
the ringtone yourself. This way, the user hears the ringtone you want
him to hear, and the phone (and any other signal-level node) knows
that the call is ringing. My hope for 183 is that it does not get
used as a generic "ACM -- set up media" type of message that depricates
180-182. It is a suppliment to fill in the gaps that 180-182
leave.

>2) Network announcements, such as "The number you have reached has been

Wouldn't a "410 The number you have reached has been disconnected"
message serve the same purpose for native clients? I sure would
prefer to read the text on a display than suffer through the
recording. I beleive this is a more appropriate approach if
you *know* for a fact that you're terminating on a native client.
If you don't know whether you're hitting a PSTN gateway, I'd
argue for playing the announcement.

This is a fairly trivial task to accomplish by doing a simple
mapping of release codes to appropriate SIP codes in the
PSTN gateway; e.g.:

ISUP    SIP
1       410 Number Disconnected
2       404 No route to network
3       404 No route to destination
8       503 Call has been preempted

etc.

My contributions to the call flows draft will go over this in
more detail.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Feb 2000 14:12:50 -0500

I agree that having a 4xx/5xx immediately is preferable. The only
strange thing is that if the announcement is long (including infinite -
I don't know how many times the number change or area code change
announcement is repeated in the PSTN), the other side hangs up, but
can't really send a BYE, since there never was a successful call to
begin with. When should the calling gateway stop sending audio?

Termination audio seems much closer to a success, from a UA perspective.
If there's a human or PSTN gateway at the calling end, it seems like the
behavior is closer to success, including hanging up to terminate the
announcement, than a failure. Clearly, even for humans, some distinct
status code (other than 200) should be provided.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 11 Feb 2000 15:59:27 -0500

You are right on the mark here.  Comments below.

> will adequately describe the state.

Yes!

> 180-182. It is a suppliment to fill in the gaps that 180-182

Absolutely!  Using 183 when a more descriptive status is available
looses information. That can only serve to limit the knowledge that the
UA has and subsequently diminish what it can do to improve the user
experience.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 11 Feb 2000 16:15:02 -0500

It seems that your argument is for early media, not necessarily
for a 183 status.  The point I have been trying to make is
that the status 183 is too generic if the outcome is known
to be a call setup failure. One should avoid using the status
183 if a more descriptive status can be provided.

Early media makes sense with many different status.  I think
that we need to be very careful in keeping these issues
separate.

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Feb 2000 00:04:19 -0600

> argue for playing the announcement.

As I understand it, the SS7 release code is often quite vague, and certainly
doesn't convey the "NEW NUMBER IS . . . " information contained in the voice
recording.

AS for 180 with ring-SDP -- how does the network gateway anticipate the ring
treatment that will be applied by a domestic terminating switch? Can't, can
it?

I'd suggest that the easiest general solution is to send a 183 with media
following the ACM. This gets the RTP stream established in time for network
call treatment.

I don't think I think 183 is an edge condition -- I think it is far more
lilkely to be the norm for PSTN interworking.

--
Dean

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 15 Feb 2000 11:01:57 -0600 (CST)

>doesn't convey the "NEW NUMBER IS . . . " information contained in the voice

Grab Q.850. On page Page 5, cause code 22 -- what is the information
conveyed in the diagnostic field? Regardless of how often this is used,
my argument is that, if it is present, it would be appropriate to return
it as a 410 message to the client instead of reading the announcement.

In the cases that the release code is too vague to determine this
information, you are absolutely correct: a 1xx early media message 
is the only available method for conveying the error information
to the user (unless you want to set up a full call, which may
have billing implications, depending on your network architecture).

>following the ACM. This gets the RTP stream established in time for network

You're right. My mistake (for some reason, I was thinking that ACM had
event code as an optional parameter). I'd argue that this situation would 
be best handled by the 183 for early media, followed by an SDP-less 180 
when and if a CPG arrives with an event code of 1 (alerting) present.

It's far less elegant than I was hoping, but it works.

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Feb 2000 18:47:40 -0600

My argument is that you MUST send a 18x with early media immediately after
receiving an ACM in order to have a media path established JUST IN CASE
there is an unsignaled in-band call treatment. Every time, all the time, in
a PSTN gateway.

I believe this should be a 183 rather than a 180 due to the semantic
difference -- a 180 means that something is being alerted, whereas a 183
just means that something is happening. This distinction allows UACes and
proxies to be a little smarter about how the use the 18x message.

Where some sort of release code can be determined, I firmly concur that the
call should be appropriately finalized.

--
Dean

> -----Original Message-----
> From: Daniel G. Petrie [mailto:[email-masked]]
> Sent: Friday, February 11, 2000 3:15 PM
> To: Dean Willis
> Cc: Adam B. Roach; Srinath Subbarayan; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: When to send 183?
>
>

---

From: Mart Nurmet <[email-masked]>
Date: Mon, 28 Feb 2000 14:23:49 -0600

I am looking for information if there has been any work done to generate a
billing package for SIP.  From my look at the available information there does
not seem to be any.  Is that the case or am I missing something?

Thank you,
-Mart

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Feb 2000 16:49:58 -0500

There is no standardized "billing package" for SIP. There will be a MIB,
and there are local log and transaction records generated by servers and
gateways. This information can be collected to bill in any way you like.

-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: Dean Willis <[email-masked]>
Date: Tue, 29 Feb 2000 13:41:02 -0600

What would a billing package look like? I've never really understood the
concept, and it might be useful to talk about it some more.

Here's how some implementors are doing it:

1) Gateways throw CDRs using RADIUS or something similar. This feeds into
rating, reporting, and billing systems,

2) SIP servers record transaction logs. These may feed into rating and
billing systems, and probably feed into reporting systems.

3) QoS PEP and PDPs log resource usages. These feed upstream as well.

4) Other systems, like profile managers, report usage.

5) Rating, reporting, and billing systems sift thru the vast amounts of
information coming at them and make useful things happen.

All of these things use other protocols and systems -- they aren't SIP
specific. They do rely on SIP functions like authentication -- that is, the
goal of achieving billing functions has driven some requirements into the
design of SIP. However, other than driving some requirements to SIP, such
efforts are generally considered to be outside the scope of the SIP WG.

Are you perhaps proposing to add functionality to SIP to simplify or enhance
reporting capabilities or to simplify the task of driving downstream billing
systems?

--
Dena
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mart Nurmet
> Sent: Monday, February 28, 2000 2:24 PM
> To: [email-masked]
> Subject: Information request! (Billing Package?)
>
>