Subject: [Sip] RE: reason code in BYE/CANCEL (was [Sip-implementors] another pro blem related to multiple call l egs at UAC)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 01:31:30 -0400

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 5:04 PM
> To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: reason code in BYE/CANCEL (was [Sip-implementors] another
> problem related to multiple call l egs at UAC)
> 
> 
> 
> Jonathan Rosenberg wrote:
> >
> >
> >  Moving from sip-implementors to sip since there are some 
> open issues and
> > changes to bis in here.
> >
> >
> 
> <snip>
> > Barry Desborough wrote:
> >
> > > I also agree that encoded reasons should be added to BYEs and
> > > CANCELs such
> > > that a PSDN gateway can map them to and from Q.931 cause codes.
> >
> > I also like these BYE reasons. This has come up countless 
> times. Its also
> > helpful in CANCEL, to know whether a call was cancelled 
> because the caller
> > aborted, or because some other branch picked up (the former 
> would generate
> a
> > missed call entry in a call log, whilst the other won't). I 
> don't think
> > Warning is right, but some kind of header that conveys both a
> > machine-interpretable and human-interpretable value would be good.
> >
> How about a "Reason" request header (or is that already 
> defined elswhere)
> that uses the same format as the Warning header?
> 
>         Reason        =  "Reason" ":" 1#reason-value
>         reason-value  =  reason-code SP reason-agent SP reason-text
>         reason-code   =  3DIGIT
>         reason-agent  =  host [ ":" port ]
>                           ;  the name of the server adding
>                           ;  the Reason header, for use in 
> tracing/debugging
>         reason-text   =  quoted-string
> 
> 
> 

Reason is not used. Seems reasonable for the header name.

I'm not sure the reason-agent is needed. 

The trick is defining the codes. A few I can think of:

400 Caller hung up
 
  this would be in a CANCEL if the UAC hangs up before an INVITE generates a
final response, or in a BYE at any point later. Its the normal call
termination case.

401 INVITE succeeded elsewhere 

  this would be in a CANCEL generated because an INVITE generated a 2xx on
another branch.

402 media stream failure

  this would be in a BYE that was sent because there was some failure in the
media streams or something like that.

other suggestions?

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.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: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jun 2001 10:27:46 -0400

Didn't Dave Oran float a proposal a month or two ago that included
something like this? I think it might even have used the "Reason"
header. I'd ask him, but I think he is away.

	Paul Kyzivat
	Cisco Systems

---

From: Michael Hammer <[email-masked]>
Date: Tue, 26 Jun 2001 11:27:39 -0400

Yes, he did, in an email dated 5/11/2001.  Do you need
a copy?

Mike

At 10:27 AM 6/26/2001 -0400, Paul Kyzivat wrote:

Didn't Dave Oran float a proposal a month or
two ago that included

something like this? I think it might even have used the
"Reason"

Paul
Kyzivat

Cisco
Systems

Jonathan Rosenberg wrote:

Reason        =
"Reason" ":" 1#reason-value

reason-value  =  reason-code SP reason-agent SP
reason-text

reason-code   =  3DIGIT

Sip mailing list
http://www.ietf.org/mailman/listinfo/sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jun 2001 13:41:52 -0400

Michael Hammer wrote:
> 
> Yes, he did, in an email dated 5/11/2001.  Do you need a copy?

No, I guess not. After you provided the particulars I find I still have
it. But from what I can see I don't think it was ever published. And
others in this discussion were also on it:

Internet Engineering Task Force                                   SIP WG
Internet Draft                                Schulzrinne/Oran/Rosenberg
draft-schulzrinne-sip-reason-00.txt        Columbia U./Cisco/dynamicsoft
May 11, 2001
Expires: November 2001

Did the authors reconsider and decide not to publish this? I don't find
it on the IETF site.

	Paul

---

From: Brian Gracely <[email-masked]>
Date: Tue, 26 Jun 2001 14:01:03 -0400

Dave never published it to I-D archives.   It just got circulated amongst 
some folks with similar email addresses as Dave's and with Henning & 
Jonathan.   A few other discussions we going on at the time on the aliases 
over whether headers like this we're too ISDN-like, so he didn't want it to 
get caught-up in the other "discussions".

BG

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jun 2001 08:55:08 +0300

Hi,

Some example of codes that maybe could be useful.

403 Session-timer expired

This would be used if the call is released when the session-timer
expires.

404 Another leg chosen

This would be useful IF we allow CANCELs and pre-call-setup BYEs for
specific call-legs (discussion on this in another thread...)

405 Service not available

This could be used for many purposes. One example could be some kind of
calling card/pre-pay call service. When the caller runs out of money, or
the call time limit is exceeded, the call could be terminated using this
Reason.

406 Client error

This would be used if the client, for any internal reason, must
terminate the call. Load balancing is one example where this could be
used. Another example is if the call state somehow gets messed up in the
client, and it deciedes to release the call. 

This Reason could also be used, for the same purpose, by proxies, or
there could be a separate Reason value for those (407 Proxy error)

A couple of issues, though:

Issue 1: Use existing codes

Before we start defining a new set of codes, I DO think that we should
have a look at the existing response codes, and see if they (or part of
them) can be used for the Reason header. Then, if we define new codes,
they may also be used for responses.

Issue 2: ISUP-SIP

I assume this COULD also affect the ISUP-SIP mapping, IF different
Reason header values will produce different mapping. I guess Gonzalo can
comment on this.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Michael Hammer <[email-masked]>
Date: Wed, 27 Jun 2001 10:12:13 -0400

Comment below.

>they may also be used for responses.

One of the key values of the reason code is that it can be sent in forward 
requests, not just backward responses.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 Jun 2001 17:38:02 +0300

Hello Christer,

> they may also be used for responses.

I agree with this. Being able to use the same code in a response and in
a BYE would be very useful for 3pcc. 

> Reason header values will produce different mapping. I guess Gonzalo can

We will be sending the REL message (with the cause code) in the BYE's
body. I do not think we want to come up with a new mapping of cause
codes to BYE reasons. However, the mapping from cause values to status
codes is already done. We might want to use existing status codes for
BYEs' reasons (like in the previous point).

Best regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jun 2001 12:29:59 +0300

Hi,

If we are going to add the Reason header, I think it now would also
would be a good idea to allow the Retry-After header in requests (BYE
and CANCEL). For example, if the called party sends a BYE because of
some internal, or whatever, reason, it may then indicate when the caller
could be able to re-establish the call.

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 28 Jun 2001 17:42:10 +0300

Hello Christer,

The retry-after header has transaction semantics. If I receive a
retry-after in a BYE I will try to send another BYE after the timer
expires...

What you want is something with call/session semantics.

This might be implementing using REFER. We could provide in a REFER the
time when we want the request to be sent (besides the request-URI,
method, etc, which is already provided in a REFER).

Regards,

Gonzalo