Subject: [SIP] Porposal for providing additional error information to UACs

From: "Dave Oran" <[email-masked]>
Date: Tue, 6 Jun 2000 16:13:45 -0400

Besides PC-like devices and big-hunking PSTN gateways, there are going to be
a gaggle of apppliance-like SIP UACs: phones, cable modems, bricks, and
other real "line-side" user devices out there.

Some of these have limited flash and essentially no user programmability. It
also is pretty important to keep the amount of provisioning and
configuration stuff on such devices to a minimum.

One area I've been playing around with is the issue of how to report SIP
error responses to the user of such a device. The basic philosophy of SIP,
of course, is to return the error
response, with possibly some ascii text, and let the UAC figure out what to
do. Letting the UAC control this is great - just what we want - so I've been
considering the options for "what to do".

One thing I don't want to do is have some fixed mapping table of error codes
to tones and announcmeents in the UA iteself. This is hard to provision
(national variants, multiple languages, etc.), takes lots of memory, etc.
etc. and while tractable for, say a SIP phone with a display, what about:
  - black phone attached to a SIP brick, or
  - a SIP phone with no display, or
  - a blind user.

One idea I find rather appealing is to allow a Contact header on any
response (not just redirects) and use that to point the UAC via a URL to
some kind of server which can give more feedback about the error. Servers
might include an RTSP server, a fancy speech synthesizer with computed
content, or just an ftp: url to an audio file. So, for example, you could
do:

     SIP/2.0  480 No Response
     Via: SIP/2.0/UDP here.com:5060
     From: BigGuy <sip:[email-masked]>
     To: LittleGuy <sip:[email-masked]>
     Call-ID: [email-masked]
     CSeq: 1 INVITE
     Contact:
rtsp://annoucements.here.com/english/you-lose.mp3?[email-masked]
     Content-Length: 0

and the SIP UA would then use the URL to get to the rtsp server, which would
play the announcement "sorry, but the number you have reached,
[email-masked], is out of service, if you need assistance, tough luck - you
think this is AT&T? (just kidding)".

I thought of some alternative mechanisms, but rejected them as follows:

a) putting the url in the text area of the response header: not good because
we don't want to pre-empt that fallback, and because there might be parsing
difficulties in deciding whether to treat the text as a url.
b) use a URL pointer body part: how do you indicate that the semantics of
this body part is something to contact? The contact just seems more natural
for this.
c) invent a new header field: then we get into debates whether that other
thing belongs to 200/300 responses
d) use a new redirect code, something like "387 More Information": this
takes the control out of the hands of the UAC, since now the policy for
whether to just return the "original" error response or remap it for this
particular UAC now has to be made by a proxy, or worse, by the UAS that
rejected the call.

If people think this is a good idea, we could add this to some existing
ongoing SIP WG item, or alternatively I could write a brief I.D. describing
this. A whole Internet-draft for something so minimal seems overkill, but
whatever works for folks...

Thanks to Jonathan and Henning for screening an earlier version of this and
providing some initial feedback (don't blame them!).

Comment? Bricks? "380 Go to Jail, go directly to jail, do not pass go, do
not collect $200"?

Dave Oran.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 06 Jun 2000 16:37:05 -0400

Tentative wording is in the current (June 5) 2543bis-00 draft:

\begin{changebar}
\item[4xx, 5xx and 6xx responses:] The \header{Contact} response-header
field can be used with a 4xx, 5xx or 6xx response to indicate the
location where additional information about the error can be found.
\end{changebar}

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Jun 2000 15:36:28 -0500

Dave Oran wrote:
[...]
> response (not just redirects) and use that to point the UAC via a URL 
> to some kind of server which can give more feedback about the error. 
> Servers might include an RTSP server, a fancy speech synthesizer with 
> computed content, or just an ftp: url to an audio file. So, for 
> example, you could do:
> 
>      SIP/2.0  480 No Response
> and the SIP UA would then use the URL to get to the rtsp server, which 
> would play the announcement 
[...]

Cool.  That is similar to storing AVP in LDAP directories, where the
value of the attribute is a generalized URL from where the actual
information can be retrieved.  Been lucky enough to use such frameworks
with great success...

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
IN Architecture and Internet Software Group
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

---

From: "Dave Oran" <[email-masked]>
Date: Tue, 6 Jun 2000 16:54:47 -0400

Works for me!!!!

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Henning Schulzrinne
> Sent: Tuesday, June 06, 2000 4:37 PM
> To: Dave Oran
> Cc: IETF SIP WG
> Subject: Re: [SIP] Porposal for providing additional error information
> to UACs
> 
>

---

From: Jon Steer <[email-masked]>
Date: Tue, 06 Jun 2000 17:05:29 -0400

At 04:13 PM 6/6/00 -0400, Dave Oran wrote:

Why isn't a redirect to a regular announcement server by
the destination the preference here?

Isn't there a problem with redirecting a UA device?

Wouldn't it be simpler to instead define an
announcement server that could use the
error message as an address which is
more likely in the UA's domain?

So in my scenario,

  UA1 -> calls UA2 gets an error message
  UA1 then calls Announcement server A using
  the error message/error number as a destination
  and gets a media stream returned in the
  language of choice.

This way, the announcement server shows up
in the normal SLP/DNS directory service
and the UA can use it if it wants to.

regards,
jon

---

From: "Dave Oran" <[email-masked]>
Date: Tue, 6 Jun 2000 17:42:11 -0400

> From: Jon Steer [mailto:[email-masked]]
> Sent: Tuesday, June 06, 2000 5:05 PM
> To: Dave Oran; IETF SIP WG
Because that moves the policy for what to do from the UAC to a proxy or UAS.
I want the UAC to decide what to do based on what it finds most convenient
without other elements in the network trying to second guess it's
capabilities or the preferences of the user using it at the moment.

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 06 Jun 2000 16:45:35 -0500

Dave Oran wrote:
> or alternatively I could write a
>brief I.D. describing

The lenght of an I-D says nothing about its value.
Go for it!

Henry

>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Dave Oran
>Sent: Tuesday, June 06, 2000 3:14 PM
>To: IETF SIP WG
>Subject: [SIP] Porposal for providing additional error
>information to
>UACs
>
>

---

From: Scott Petrack <[email-masked]>
Date: Wed, 7 Jun 2000 00:55:19 -0400 (EDT)

Sorry that I've not been following this too closely, so apologies if
the following makes no sense or has already been rejected: but this is
really what I wanted a Warning: header to do. I agree with you that the
extra indirection can be very useful, but if all you want is some minimal
extra information, then a single line of text inserted by the last SIP
proxy before the SIP appliance can be very useful. 

Remember, the text in this Warning: header can be tagged for what
language it's in, etc, so that the appliance can be configured to show on
the screen only messages in swahili, whatever. 

If you are going to put a URL to allow the appliance to retrieve the
error, I suggest a new header, rather than the Contact: header. Something
like Warning-URL: or Error-URL:
or even just Display-URL: (the appliance doesn't really need to know if
the stuff to be retrieved and displayed is a warning or some extra info.
The same mechanism could be used for "extra lookups" sort of as if there
were an end-to-end calling-party identification service).

Scott

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 07 Jun 2000 01:41:10 -0400

> were an end-to-end calling-party identification service).

Whether to use Contact or a new header depends a lot on how you want to
define the precise semantics of the header. If you use the loosest
definition, which is "go here", then Contact will suffice. In fact,
using Contact has the advantage of being able to also use the caller
preferences capabilities. The UA can, in the INVITE, indicate that it
only knows about sip URL schemes. This way, your redirecting device
would not try to send the UA to an rtsp URL, rather it might redirect
the UA to an app server which contacts the RTSP server and streams the
content to the UA. 

However, if your definition of Contact is "try this address to reach the
desired party", probably Contact is not the right thing. As Dave has
pointed out, proxies can recurse on 3xx and attempt to reach the
addresses in a Contact header because the meaning is precisely "try this
address to reach the desired party", and thus its fine for the proxy to
try that address. But, Dave doesn't want proxies to go to these
addresses - they should only be used by the UA upon receipt of the
reject response.

So, I'm a bit on the fence, but probably inclined to define a new header
in order to avoid further overload of exactly what Contact means. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 07 Jun 2000 08:59:33 -0400

> addresses - they should only be used by the UA upon receipt of the

I'm not sure this is different from "this address is only to be used in
case the original address isn't reachable" (3xx).

> in order to avoid further overload of exactly what Contact means.

Since there is no ambiguity in the action to be taken, I'm not in favor
of defining a new header. Defining a new header then means worrying
about whether *it* has meaning for 3xx or 2xx responses. Thus, in terms
of economy of definition, this one-paragraph version seems to be the
lowest-cost way of achieving additional error explanation capability.
Any new header also increases the chances for misunderstandings, with
various combinations of the new and Contact header.

---

From: "Dave Oran" <[email-masked]>
Date: Wed, 7 Jun 2000 09:45:46 -0400

This has been a good discussion. Sonce I'm basically interested in getting
the functionality, I'm not strongly wedded to whether we define a separate
header, or use Contact. Contact certainly seems the course of least
resistance, as Henning and Jonathan point out, and I agree.

To respond to Christian Heuitema's message, if all I was trying to do was
get access to an announcement server that played error-response-dependent
audio or did something fixed, then I agree that there's no need for
enahncing SIP itself. However, I want to factor out the UAC policy about
what it does when it gets an error reponse from how the alternatives for
what it could do are presented. It seems for flexibility it makes sense to
allow the protocol to carry the alternatives.

Getting back to thge issue of Contact vs. new header, I did, however, think
of one reason why a separate header provides more flexibility, which may
also alleviate Henning's (and my) concern about what such a header would
mean on a 2xx or 3xx.

Let's suppose you do get a 3xx-style redirect. If we had a separate header,
like Scott's proposed "Error-URL:" the UAC could *both* act on the URL,
*and* retry the invite to the parties listed in the Contact: header.

For example, let's suppose I'm on vacation, and I set my UAS (or my local
proxy) to reject the Invite with a 302 Moved Temporarily, with the contact
field set to, say, my voicemail server, and the new header set a URL which
points to an audio file that says "Sorry I'm away, you'll have to talk to my
voicemail". The UAC could then access the message either before retrying, or
in parallel with retrying to the voicemail.

Don't know if people find this example useful, but it might stimulate
further discussion and hopefully consensus.

Dave.

> Sent: Wednesday, June 07, 2000 9:00 AM
> To: Jonathan Rosenberg
> Cc: Scott Petrack; Dave Oran; IETF SIP WG
> toUACs

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 09 Jun 2000 10:02:34 -0700

>content, or just an ftp: url to an audio file. So, for example, you could

This is a great idea. I can see how implementers would have had specialized 
hooks in their phones to do this anyway. That would have led to a lot of 
user confusion and complaints of too much complexity with SIP phones. This 
makes things easy and perhaps more important even for everyone by allowing 
for it in the protocol.