RE: [Sip] Reason header simplification

["David R. Oran" <oran@cisco.com>]

This approach seems eminently reasonable to me.

For documentation purposes it probably makes sense to have a table which
says which "response codes" make sense in Reponses only; which make
sense as reason codes in requests only, and which makes sense in both.
Even if all make sense in both, it's important to document the usage
subtleties.

I'm agnostic on the issue of whether we should both caring additional
information beyond a text of the reason in the reason header.

Dave.

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of Eric Burger
> Sent: Tuesday, March 19, 2002 5:12 PM
> To: Rohan Mahy
> Cc: sip@ietf.org
> Subject: RE: [Sip] Reason header simplification
> 
> 
> 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
> 


_______________________________________________
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