RE: [Sip] Reason header simplification

["Eric Burger" <eburger@snowshore.com>]

The reason for Reason :-) is for the "extra info" that's behind the result
code.  Sort of an Error-Info short-hand (should it be such?).

A model that this reminds me of is the VAX VMS return structure.  There's
the return code (which I agree with Rohan, is simply the SIP return code).
Then there's the readable text.  Then there's the useful info.

Clearly the "useful" info is situation-specific.  This is where the rest of
the Reason information, *including* Q.mumble, H.foo, Unix Process Exit
Value, etc. is important.

The other place for Reason is to address History.  The SIP result code is
for *this* request.  There's a need for knowing other result codes this
request has been exposed to during its life.

I would propose a Reason: header that is composed of the *SIP* result code
(as Rohan suggests) with enriched, application-specific information (as
Henning/Gonzalo suggest).


-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Rohan
Mahy
Sent: Tuesday, March 19, 2002 3:32 PM
To: gonzalo.camarillo@ericsson.com
Cc: sip@ietf.org
Subject: [Sip] Reason header simplification


Hi,

It occurred to me that there is a lot of overlap between the 1-9 reason
codes in the reason header, and the 3 digit SIP reason codes.  I think
these could be consolidated as described below.

Reason: 1 (call completed elsewhere) in a CANCEL could instead become a
CANCEL with a Reason: 200 OK (you are receiving a CANCEL because the
status of the call was a 200 OK, presumably from another branch).

The only difference between Reason 2 (abandoned) and Reason 4 (terminated)
is that 2 is used in CANCEL, and 4 is used for BYE.  We could allocate a
new 4xx response code (say 499) for "terminated" and use this instead.
This response code would also be useful in the call-info package.

Reason: 3 (timed out) is easily expressed with Reason: 408 Timeout

Reason: 5 (transfer complete) isn't needed because a notification to that
effect is generated when using REFER

Reason: 6 (no media) could be represented with a new response code (say
498)

Reason: 7 (interworking) does really have any semantic meaning, so just
use the SIP response code.

Reason: 8 (offer refused) sounds like a 603 Decline or 488 Incompatible
Media to me.  The SIP responses are actually more rich, but not
significantly more complex.

Reason: 9 (update requested) can be implied by the fact that the reason
header is in a 155 response.  the "real" reason is the repairable error


Also I don't like to idea of sending ISUP (Q.850) or ISDN (Q.931) response
codes around inside a SIP network.  I'd rather use standard ISUP-SIP or
ISDN-SIP cause code translation, so that an ordinary SIP UA can just use a
set of well-defined SIP cause codes.

hope this makes sense.

thanks,
-rohan





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip