Subject: [Sip] Reason format: removing reason codes

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 08 Apr 2002 13:59:49 +0300

Hello,

There has been some discusion about the format of the Reason header
field. Right now this header field contains, besides a SIP status code
and the reason phrase, a reason-code. This is a new code that identifies
the reason why the request was sent. 

http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt

It has been proposed that we get rid of this reason code and use only
SIP status codes. I have analyzed several scenarios where the reason
header field may be useful to see if we can cover all our requirements
by using only status codes:

1) 155 responses. In this case we do not need anything besides the
status code of the final response.

2) CANCEL or BYE is sent because another branch has picked up. In this
situation a Reason header field with a 200 OK inside would do the work.

If the CANCEL or BYE have been sent because the user was tired of
waiting for the callee to answer (or hanged up in the middle of the
session), a 603 decline can be included.

This has the good property that it would work in the same way for 3pcc:

     A         Controller             B

     |              |                 |
     |              |----INV--------->|
     |              |<-200 OK SDP-----|
     |              |--ACK held------>|
     |<-----INV-----|                 |
     |-603 decline->|                 |
     |<----ACK------|                 |
     |              |-BYE Reason 603->|

In this 3pcc scenario, if A returns a 486 busy, the status code is
encapsulated in the Reason of the BYE as well.

3) BYE or CANCEL because no media was received.

We do not have a status code for this. However, we could create one,
since it may be also useful for response. For example, an application
server receives an INVITE and sends back a 183 to establish early media.
It needs to get a pin number using voive recognition. If after a while
no media has been received, the application server can respond with the
new status code 4xx No media received.

4) re-INVITE for refresh and re-INVITE to try to solve network problems.
In the first case the UAS wants to respond with the current SDP, but in
the second case the UAS might want to provide an alternative network
address, for instance. The status code defined above in 3) could be used
here.

4) When an unacceptable offer that cannot be refused (i.e, it came in
the 200 OK for a re-INVITE) is received.

  |-re-INVITE----------->|
  |<--200 OK SDP 1-------|
  |----ACK SDP 2-------->|
  |                      |
  |--BYE reason 488----->|

The SDP in the ACK is well formed, but it is useless since the SDP in
the 200 OK is unacceptable for the UAC

488 would also cover the scenario below, when a re-INVITE is refused and
the UAC does not want to continue with the session, since its re-INVITE
was refused.

  |-re-INVITE-SDP 1----->|
  |<--200 OK SDP 2-------|
  |----ACK-------------->|
  |                      |
  |--BYE reason 488----->| 

As I said in a previous mail, I believe that the reason why an initial
request (outside a dialog) has been sent is outside the scope of
"Reason". I can specify why I am sending an INVITE using the subject
header field, or the s= line of SDP (or a referred-by type of
mechanism).

So, what folks think about getting rid of the reason codes and keeping
only SIP status codes?

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 08 Apr 2002 13:41:23 -0500

> Hello,

Gonzalo:

Comments inline.

> SIP status codes. 

That's fine.

> status code of the final response.

155 is probably the only response to which the Reason header field
adds any value (183 was finally rejected after a few emails on the
WG list).  I really think the I-D should specify that Reason header
makes sense for 155 responses *only*.  Otherwise we will have simply
too many ways to send responses -- normal SIP response codes, Warning
header (which also carries information about the status of a response),
and now, using Reason for sending a response.

> since it may be also useful for response. 

This is tying it to a specific application.  Could we not achieve the
same result by encapsulating a "400 No Media Received" into a Reason
header as follows:

    BYE sip:mediaserver.net SIP/2.0
    Reason: 400;text="No Media Received"
    ...

Come to think of it, do we need the "triggered" parameter.  If there
is not going to be a "SIP/3.0" (is there?) then why duplicate
the SIP version already present in the R-URI?

> header field, or the s= line of SDP (or a referred-by type of

In that case, we should just mention that using the Reason header
outside of a dialog is outside the scope of this I-D (and that
Subject or some other means can be employed for that purpose).

Best regards,

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 09 Apr 2002 11:16:39 +0300

Hi,

> and now, using Reason for sending a response.

Yes, 155 is the only response that can carry a Reson header field. I
will update the draft as soon as I have the time.

> same result by encapsulating a "400 No Media Received" into a Reason

well, I would say that "No Media Received" is general enough to be a
status code on its own, but your point of view is also valid. I would
like to hear more opinions.

> the SIP version already present in the R-URI?

the triggered parameter is useful if we want to encapsulate Q.850 or
other stuff like that. Anyway, that is a different discussion. Let's
first agree on the reason codes and then decide if we only carry SIP or
something else.

Regards,

Gonzalo