Info/request from customer


Report something useful so that the user understands what's up
(or can tell his/her helpdesk what the box said).

Logging in to the phone using telnet to find this out is not useful in real life scenarios. trust me, you do not want to login (using telnet) to your users' phones over the internet just to find out if he got back a 416 or a 404.

It is also not very secure to use telnet for remote connections.

Reporting of actual (XXX) error code could be an option, but should be configurable.

"Reorder" is bad. it tells the user to actually try again, which will not help most of the time since an error occurred that will not be resolved by itself.

Error CodeTodayWanted
100 Trying"Proceeding (in 100)""Trying (100)"
180 Ringing"Ringing Destination (in 180)""Ringing (180)"
181 Call Is Being Forwarded"Proceeding (in 100)""Call Is Being Forwarded (181)"
182 Queued"Proceeding (in 100)""Queued (182)"
183 Session Progress-"Session Progress (183)"
200 OKN/AN/A>
300 Multiple Choices"Reorder""Error (300)" (not implemented)
301 Moved Permanently"Reorder""Error (301)" (not implemented)
302 Moved Temporarily"Reorder""Error (302)" (not implemented)
305 Use Proxy"Reorder""Error (305)" (not implemented)
380 Alternative Service?broken?
400 Bad Request"Reorder""Bad Request (400)"
401 Unauthorized"Reorder""Unauthorized (401)"
402 Payment Required"Reorder""Payment Required (402)"
403 Forbidden"Reorder""Forbidden (403)"
404 Not Found"Reorder""Not Found (404)"
405 Method Not Allowed"Reorder""Method Not Allowed (405)"
406 Not Acceptable"Reorder""Not Acceptable (406)"
407 Proxy Authentication Required"Reorder""Authentication Failed (407)"
408 Request Timeout"Reorder""Call Timeout (408)"
410 Gone"Reorder""Not Found (410)"
413 Request Entity Too Large"Reorder""Request Entity Too Large (413)"
414 Request-URI Too Long"Reorder""Request-URI Too Long (414)"
415 Unsupported Media Type"Reorder""Unsupported Media Type (415)"
416 Unsupported URI Scheme"Reorder""Unsupported URI Scheme (416)"
420 Bad Extension"Reorder""Bad Extension (420)"
421 Extension Required"Reorder""Extension Required (421)"
423 Interval Too Brief"Reorder""Interval Too Brief (423)"
480 Temporarily Unavailable"Reorder""Temporarily Unavailable (482)"
481 Call/Transaction Does Not Exist"Reorder""Call/Transaction Does Not Exist (481)"
482 Loop Detected"Reorder""Loop Detected (482)"
483 Too Many Hops"Reorder""Too Many Hops (483)"
484 Address Incompleteoverlap dialing. implemented?
485 Ambiguous"Reorder""Ambiguous (485)"
486 Busy Here"Line Busy" + SLOW BUSY"Line Busy (486)" + SLOW BUSY
487 Request Terminated"Reorder""Request Terminated (487)"
488 Not Acceptable Here"Reorder""Not Acceptable Here (488)"
491 Request Pending"Reorder""Request Pending (491)"
493 Undecipherable"Reorder""Undecipherable (493)"
500 Server Internal Error"Reorder""Server Internal Error (500)"
501 Not Implemented"Reorder""Not Implemented (501)"
502 Bad Gateway"Reorder""Bad Gateway (502)"
503 Service Unavailable"Reorder""Service Unavailable (503)"
504 Server Time-out"Reorder""Server Time-out (504)"
505 Version Not Supported"Reorder""Version Not Supported (505)"
513 Message Too Large"Reorder""Message To Large (513)"
600 Busy Everywhere"Reorder""Line Busy (600)" + SLOW BUSY
603 Decline"Reorder""Call Rejected (603)"
604 Does Not Exist Anywhere"Reorder""Not Found (604)"
606 Not Acceptable"Reorder""Not Acceptable (606)"

Info from Cisco:


The error codes for 486 busy here use to be shown on the phone display but they is "line busy". 404 not found use to be shown and reorder is now shown.

In the opinion of the developer there is no need to display SIP error messages to the end user. As for Administrators, they can telnet or console into phones and enable debugging to determine actual error codes.


(1) Short problem description:

Unusable error codes.

(2) Longer problem description (what happens):

When the 7960 can not set up at call, it will only report 'Reorder' to the user and a fast-beep emits. User is confused and support has a big problem trying to find out what went wrong (see tcpdump below).

(3) Possible solution (what did you expect):

Report the SIP error code and message to the user, e.g.:
The users are not stupid and the error messages makes sense even for a non-techie.

To be more precise, it is important that the phone displays the error string which the server sends to it. That way the server/phone interaction can be made to "make more sense" in a special environment. The messages sent from the server can be fine-tuned to be applicable to the local environment.

(4) How to reproduce (if possible / applicable):

Call someone that's busy or doesn't exist.

(5) Workaround used currently (if applicable):

Use tcpdump or tethereal to peek into the packets.

(6) The behaviour wanted exists in product (name manufacturer and product as exactly as possible):

Snom

(7) Would you classify this as:

(B) Missing feature: Can not deploy before fixed

(8) Version:

Software: P0S3-05-1-00

(9) Contact Information:

Jakob Schlyter <jakob@SPAM.crt.se>
Leif Johansson <leifj@SPAM.it.su.se>

(11) Report:

Date: Wed, 25 Jun 2003 09:14:40 +0200 (CEST)
Message-ID: <Pine.OSX.4.56.0306250904220.8879@criollo.schlyter.se>

Message-ID: <3F1FE158.4070206@it.su.se>
Date: Thu, 24 Jul 2003 15:38:32 +0200