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
> 