Subject: [Sip] Reason header simplification

From: Rohan Mahy <[email-masked]>
Date: Tue, 19 Mar 2002 12:32:16 -0800 (Pacific Standard Time)

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 19 Mar 2002 17:11:43 -0500

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: [email-masked] [mailto:[email-masked]]On Behalf Of Rohan
Mahy
Sent: Tuesday, March 19, 2002 3:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] Reason header simplification

Hi,

hope this makes sense.

thanks,
-rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Mar 2002 16:45:07 -0600

> set of well-defined SIP cause codes.

Is this translation one-to-one? Which table did you have in mind? I
suspect that unless there's a one-to-one translation, you might want to
include both, with the user agent displaying whatever makes sense (and
leaving Q.850 codes for debugging).

---

From: "David R. Oran" <[email-masked]>
Date: Tue, 19 Mar 2002 18:20:44 -0500

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.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Burger
> Sent: Tuesday, March 19, 2002 5:12 PM
> To: Rohan Mahy
> Cc: [email-masked]
> 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).
> 
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Rohan Mahy
> 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: 5 (transfer complete) isn't needed because a 
> notification to that effect is generated when using REFER
> 
> 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
> 
> 
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 Mar 2002 03:52:05 +0200

Hello,

After the discussions we had in Minneapolis and in the mailing list, I
have thought a little more about the Reason header field.

The idea of the Reason header field is to contain "why a particular SIP
message has been generated".

The Reason header field in responses is easy, because it only applies to
155 responses.

About requests, we have several scenarios.

1) A request outside a dialog is sent, and I would like to know why it
was sent to me. This is outside the current Reason header field scope,
but it is part of the History requirements. However, in order to meet
the History requirements more information besides the reason header
field is needed. We agreed that such information (like identities) was
outside the scope of the Reason draft.

2) A CANCEL or BYE are sent within an INVITE trasaction. The Reason
header field would carry, in this scenario, what happended to the
INVITE.  The INVITE might have been answered with a 200 OK by another
branch, or the INVITE may have timed out.

3) Within a dialog, a request is sent because of the result of a
previous transaction within the dialog. For instance, a re-INVITE fails,
and I send a BYE. Or I send an empty re-INVITE and I do not like the SDP
(offer) in the 200 OK. I ACK it (with a correctly formed answer) and I
send a BYE.

4) A request is sent and the reason has something to do with the dialog
in general, not with any other SIP transaction. For example, no media is
being received, or this is just a refresh re-INVITE...

5) Interworking. In this scenario, the reason for sending the request
has to do with something that happens outside the dialog. For example, a
3pcc exchanges with me a INVITE-200 OK-ACK putting the media on hold.
When the controller tries to contact the other party, it receives a 486
Busy Here.  The controller will have to send me a BYE. But if the BYE
has a reason field, it is related to something external to the dialog.

Points 2, 3 and 4 fall clearly within the scope of the Reason header
field. The Reason header field would provide information about the
request in relation to something (a request, a transaction or the
session associated with the dialog) that is part of the dialog as well.

However, 5 is somehow different. It provides information about something
that is beyond the UA. One may claim that a 3pcc controller is just
another form of a gateway (a SIP to SIP gateway).

Note that another "external" reason for sending a BYE may be a user
hanging up. The main difference between these external reasons and 2, 3
and 4 is that the latter are typically consequence of protocol operation
and the former are triggered by "external" stimulus.

Well, these are some thoughts about the scope of the draft. I would
appreciate comments on them. I would like to know whether or not people
think that we have to include "external" reasons in the draft (right now
they are included). Once we have agreed on the scope of the draft, we
can discuss the actual format (using Reason values + reason codes as
right now, or removing the reason codes). We can also discuss later
whether or not it is a good idea to include non-SIP status codes in the
draft.

Comments/ideas are welcome.

Best regards,

Gonzalo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 27 Mar 2002 10:48:53 -0600

> have thought a little more about the Reason header field.

Gonzalo:

Some comments.

> The Reason header field in responses is easy, because it only applies to

The I-D currently says that the header is a general header; i.e. it can 
appear in any request and any response.  I think that the header makes 
most sense as a request header only (with the exception of 155).  There 
are already elaborate response codes in SIP; why add one more way of 
propagating responses.  155 is a special provisional response which 
elicits a further request (UPDATE), so the Reason header does add some 
value to a generic 155 response.  I think that The I-D should state that 
155 is the only response to which the Reason header can be applied to.

> but it is part of the History requirements.

Does this mean that the Reason header cannot be used in a request that 
establishes a dialog (like the initial INVITE to a UAS)?  I did not get 
that impression from the I-D.  If that is indeed the case, then aren't 
we limiting the header artifically?

> field.

[...]

> and the former are triggered by "external" stimulus.

This may be splitting hairs, really.  Regardless of if a BYE was 
triggered by an external stimuli, the fact that a UAS gets a BYE, 
understands it and processes it makes the BYE a consequence of the 
protocol operation.

> they are included).

I think we should (within reason [no pun intended] of course -- and that 
will be the hardest part).

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 27 Mar 2002 13:56:20 -0600

Sean Olson wrote:

>>There 
> Would a Reason: header be allowed in a 183?

I don't speak for the authors of course, but my feeling is that 183 as a 
response code is associated with QoS preconditions.  It has a well 
defined profile, so to speak.  So carrying a Reason phrase in it 
probably does not add too much.

155 on the other hand is a response code for solving the early media, 
HERFP, as well as repairable error responses.  So there is some good to 
further qualifying the 155 response for the UAC.

Regards,

- vijay

---

From: Sean Olson <[email-masked]>
Date: Wed, 27 Mar 2002 11:24:58 -0800 (PST)

/sean

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/