Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Hi Francois,
The problem is that this is not the opinion I've got in the past. I would have been happy if somebody had the same view on that issue as you have now.

And I have not seen any RFC that explicitly allows the use of Q.850 causes within responses.

Of course within ISUP the Release can be sent in both directions also before and after Answer Message (equivalent to 200 OK). So a Release Message within ISUP has the same functionality as a Response, CANCEL and BYE. And that was not really taken into consideration when the Reason Header was developed.

BR,

Roland

-----Ursprüngliche Nachricht-----
Von: Francois Audet [mailto:audet@nortel.com] 
Gesendet: Donnerstag, 16. Juli 2009 18:48
An: Jesske, Roland; Dale Worley
Cc: dispatch@ietf.org
Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Hi Roland,

You use case is very common.  

I believe you are incorrect in saying that "reasons are currently 
not allowed in responses. Neither conditionally nor allowed".

RFC 3326 says in 1.0:
  "[...] it can appear in any request
   within a dialog, in any CANCEL request and in any response whose
   status code explicitly allows the presence of this header field."

To be honest, I believe Q.850 codes are much more common in 
Responses than in requests.

> -----Original Message-----
> From: dispatch-bounces@ietf.org 
> [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
> Sent: Sunday, July 12, 2009 23:17
> To: Worley, Dale (BL60:9D30)
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04
> 
> Hi Dale,
> The main probblem is that reasons are currently not allowed 
> in responses. Neither conditionally nor allowed
> 
> Please see: 
> http://www.ietf.org/mail-archive/web/sipping/current/msg09682.html
> 
> The draft tries to close this gap and allows conditionally 
> Q.850 resasons within Resopnses. So it would be a service 
> provider decision to include Reasons in Responses when 
> mapping from ISUP to SIP.
> 
> The following call flow shows an example:
> 
>          A                Gateway             Gateway              B 
>          |        IAM        |                  |                  | 
>          |------------------>|     INVITE       |                  | 
>          |                   |----------------->|      IAM         | 
>          |                   |     100 Trying   |----------------->| 
>          |                   |<-----------------|    100 Trying    | 
>          |                   |   403 Decline    |                  |
>          |                   |  Reason Q850 #87 |  REL Cause #87   |
>          |   REL Cause #87   |                  |<-----------------| 
>          |                   |<-----------------|                  | 
>          |<----------------- |                  |                  | 
>          |                   |                  |                  | 
>          |                   |                  |                  | 
>          |                   |                  |                  | 
> 
> Due to RFC 3398 a 403 will be mapped back to a ISUP Cause 21. 
> With the Reason in responses the Cause Value 87 will be 
> secured and transferred back to ISUP.
> 
> Mheanwile I got some indications from some persons who see 
> this issue within the BLISS group due to the fact that this 
> draft solves interoperability issues within SIP and PSTN.
> 
> Views?
> 
> BR,
> 
> Roland
>  
> 
> -----Ursprüngliche Nachricht-----
> Von: Dale Worley [mailto:dworley@nortel.com]
> Gesendet: Freitag, 10. Juli 2009 21:52
> An: Jesske, Roland
> Cc: dispatch@ietf.org
> Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04
> 
> On Tue, 2009-07-07 at 07:13 +0200, R.Jesske@telekom.de wrote:
> > Hi Dale,
> > Within the SIPPING group I had already discussions on that issue.
> > The assumption was that the use of the Reason Header within 
> Responses is conditionally allowed. 
> > 
> > The RFC 3326 says:
> >    Initially, the Reason header field defined here appears 
> to be most
> >    useful for BYE and CANCEL requests, but it can appear in 
> any request
> >    within a dialog, in any CANCEL request and in any response whose
> >    status code explicitly allows the presence of this header field.
> > 
> > 
> > So we need a draft where it is stated that a reason header 
> can be included within the SIP Response. That was also the 
> recommendation of that discussion. That is why I wrote a draft.
> > Nevertheless some standards already include this behaviour 
> like the ITU-T Q.1912.5 specification.
> > Also 3GPP needs the reason header within Responses.
> 
> It is still unclear to me what is being changed.  Is the 
> change the replacement of "conditionally allowed" to 
> "allowed"?  In any case, in my mind the purpose of the Reason 
> header is to carry Q.850 cause-codes in failure responses.
> 
> The point is that the Abstract is not at all clear about the 
> change from the status quo (at least to someone who isn't 
> already thoroughly familiar with how Reason is currently specified).
> 
> And the secondary point is that if the Abstract was clearer 
> about what it is being changed, more people might read and 
> discuss the draft.
> 
> Dale
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 