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

From: Christian Huitema <[email-masked]>
Date: Tue, 6 Jun 2000 14:07:15 -0700

Dave,

I understand the intent, but find a few design problems with your solution.
First, I would rather not overload the "contact" header with this kind of
information. There are error cases in which it is legitimate to use Contact
for its intended purpose, e.g. a suggestion of an alternative target for the
call. If you want to point to some explanatory text, or voice message, you
can always use another header, e.g. "Comment."

Then, we have to think a little more about the actual intent of the comment.
It seems to me that you want to use SIP in a semi autonomous appliance, that
cannot really function well without the help of a big brother in the net. I
would rather use MGCP for such apliances, but that is another story. In any
case, you are looking at some form of distributed system. So, you could just
as well use a non-SIP channel to get the information. For example, get the
voice message for error code 107 by looking for the URL:
	 http://my.big.brother.in.the.net/explain/?code=107.
If you insist in making that part of SIP, you have to analyze who should
insert the "comment" line. Is the comment a direct function of the error
code, or does it provide additional information? Is this an end-to-end
field, or a field inserted by the last proxy? Is it covered by the
authentication checksums? Who decides in which language to put the
explanation? 

Christian Huitema

> -----Original Message-----
> From: Dave Oran [mailto:[email-masked]]
> Sent: Tuesday, June 06, 2000 1:14 PM
> To: IETF SIP WG
> Subject: [SIP] Porposal for providing additional error information to
> UACs
> 
> 
> 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
> 

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