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

From: <[email-masked]>
Date: Mon, 6 Jul 2009 13:50:23 +0200

Dear all,
After getting no response to my question from the dispatch. I assume that there is no interest on this draft within dispatch.

So now I would like to ask the people from SIPCORE and BILSS where do they see the work.

The below mentioned draft describes the use of the Reason Header within Resoponses for interoperability with the existing PSTN/ISDN networks.

Best Regards

Roland

> _____________________________________________ 
> Von: 	Jesske, Roland  
> Gesendet:	Donnerstag, 2. Juli 2009 14:39
> An:	[email-masked]
> Betreff:	draft-jesske-sipping-etsi-ngn-reason-04
> 
> Dear all,
> At the moment I'm preparing a new version of draft-jesske-sipping-etsi-ngn-reason-04 ( http://tools.ietf.org/html/draft-jesske-sipping-etsi-ngn-reason-04 ) to be submitted.
> There were some comments which were stating that this is the wrong group for the draft.
> I would like to know what the feeling of the group is to which group (BLISS, DISPATCH or SIPCORE) this draft should belong.
> 
> Thank you and Best Regards
> 
> Roland
> 
> Deutsche Telekom Netzproduktion GmbH 
> Zentrum Technik Einführung 
> Roland Jesske 
> Gateways, Protokolle, Konvergenz, TE32-1
> Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, 
> Postfach, 64307 Darmstadt (Postanschrift) 
> +496151 628 2766 (Tel)
> +491718618445 (Mobile) 
> E-Mail: [email-masked] 
> http://www.telekom.de <http://www.telekom.de/>  
> 
> 
> 
> Registerrechtliche Unternehmensangaben: 
> Deutsche Telekom Netzproduktion GmbH 
> Aufsichtsrat: Timotheus Höttges (Vorsitzender) 
> Geschäftsführung: Friedrich Fuß (Vorsitzender), Albert Matheis, Klaus Peren 
> Handelsregister: Amtsgericht Bonn HRB 14190 
> Sitz der Gesellschaft: Bonn 
> USt-IdNr.: DE 814645262
> 
>

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 06 Jul 2009 11:36:52 -0400

On Mon, 2009-07-06 at 13:50 +0200, [email-masked] wrote:
> Dear all, 
> After getting no response to my question from the dispatch. I assume
> that there is no interest on this draft within dispatch.
> 
> The below mentioned draft describes the use of the Reason Header
> within Resoponses for interoperability with the existing PSTN/ISDN
> networks.

Is the Abstract right?  As far as I can tell (by reading section 2), the
Abstract doesn't describe the draft at all.  That might be a reason that
you haven't gotten any response -- the Abstract "proposes the use of the
Reason header field in SIP responses", but that is something that is
already defined and allowed.

Dale

---

From: <[email-masked]>
Date: Tue, 7 Jul 2009 07:13:37 +0200

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.

Now due to the fact that the draft is expired and with the reorganisation of SIP and SIPPING the questioned appeared where such draft would like to fit best.
 SIPCORE, DISPATCH or BLISS.

Best Regards,

Roland  

-----Ursprüngliche Nachricht-----
Von: Dale Worley [mailto:[email-masked]] 
Gesendet: Montag, 6. Juli 2009 17:37
An: Jesske, Roland
Cc: DISPATCH
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 10 Jul 2009 15:51:32 -0400

> 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

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 08:16:54 +0200

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:[email-masked]] 
Gesendet: Freitag, 10. Juli 2009 21:52
An: Jesske, Roland
Cc: [email-masked]
Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jul 2009 13:01:24 -0400

On Mon, 2009-07-13 at 08:16 +0200, [email-masked] wrote:

> The main probblem is that reasons are currently not allowed in
> responses. Neither conditionally nor allowed
> 

That clarifies things.

Let me rephrase my complaint:  Although the text of the RFC states "The
Reason header field MAY appear in [...] any response whose status code
explicitly allows the presence of this header field.", that text is
stunningly unclear that the consequence is that the Reason header is not
allowed in *any* defined response, and a casual reader might not realize
that Reason is thus effectively forbidden in all responses.

Expanding the Abstract along these lines would make the significance and
importance of the draft much clearer:

        Although the use of the Reason header in responses is considered
        in RFC 3326, doing so is not specified for any existing response
        code.  This document specifies the use of the Reason header
        field in SIP responses to carry Q.850 reason codes for the
        failure of an INVITE.
        
Dale

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 16 Jul 2009 13:08:38 -0400

On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois (SC100:3055) wrote:
> 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
>    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.

Googling

     "sip/2.0" reason "q.850"

turns up numerous examples of SIP responses using the Reason header in
the forbidden manner.

I'd say that your draft formally allows what people are already doing.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 12:16:18 -0500

Again, the spec is very clear that it IS allowed.

I believe the wishy-washy text about "status code explicitly
allowing it" was meant to exclude responses that were not appropriate,
and restricing it to effectively error responses.

At the time this was written, I believe we were not clear on which
codes were supposed to be appropriate or not.

Seems to me:
- Any Error response code should be allowed.
- I don't think 2XX makes sense.
- 3XX is controversial (as per the email quoted by Roland): seems to me it
  would be quite useful
- Provisional is interesting... Sounds like 199 error response to me...

> -----Original Message-----
> From: Worley, Dale (BL60:9D30) 
> Sent: Thursday, July 16, 2009 10:09
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04
> 
> > 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:
> turns up numerous examples of SIP responses using the Reason 
> header in the forbidden manner.
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 11:48:11 -0500

Hi Roland,

RFC 3326 says in 1.0:

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, July 12, 2009 23:17
> To: Worley, Dale (BL60:9D30)
> Cc: [email-masked]
> 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.
> 
> 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
>  
> 
> > 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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Jul 2009 20:29:44 +0200

If by "the spec" you are referring to the original Reason header RFC 3326, then yes, it did not preclude it, but specifically indicated that any usage had to be documented further.

There are no RFCs currently specifying the use with any status code.

Note also that the rest of the text in the document is specifically about its use in requests.

If you go back, you will remember that Reason header was being addressed originally at two problems. One was the issue of transferring clearing information from elsewhere in a BYE request, the other was the HERFP problem. The latter was the use case that required things in a response, but there was no agreement on the way forward on this part of the problem. Therefore the Reason header draft was cut down only to address the first problem.

I would note that the argument has been made in the past, and indeed is hinted at in RFC 3326, is that in responses, you should use the response code. This is what SIP UAs are designed to understand and deal with on reception. Therefore it has been stated in the past that if one wishes to deliver information to end UAs that is not covered by the existing response codes, then a new status code should be defined. Therefore no general use of Reason headers in responses was given in RFC 3326 for that reason. I did not originate that argument, and maybe the people who gave that argument should speak up, but it is certainly the argument that shaped RFC 3326 the way it is.

There is a case where you need to get information from a SIP UA acting as a gateway to another SIP UA acting as a gateway and in that case the Reason header in a response would be well justified in that case, and that is certainly one of the cases covered by the draft.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: Thursday, July 16, 2009 6:16 PM
> To: Dale Worley
> Cc: [email-masked]; [email-masked]
> allowing it" was meant to exclude responses that were not 
> appropriate, and restricing it to effectively error responses.
> 
> At the time this was written, I believe we were not clear on 
> which codes were supposed to be appropriate or not.
> 
> Seems to me:

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 07:08:42 +0200

Hi Dale,
You are right. The Q.850 causes will be used within ITU-T Q.1912.5 for interworking SIP-ISUP and SIP-I.
Within ETSI ES 383 001 for interworking SIP-ISUP and SIP-I.
Within 3GPP TS 29.163 also interworking SIP with ISUP but there it is referred to the regarding draft we are discussing.

Also it is widely deployed also within our network.

But nevertheless within 3GPP meetings I have got requests to progress the ietf draft because people thinks that this is the way to ratify the use of reason within responses.

Best regards

Roland

-----Ursprüngliche Nachricht-----
Von: Dale Worley [mailto:[email-masked]] 
Gesendet: Donnerstag, 16. Juli 2009 19:09
An: Francois Audet
Cc: Jesske, Roland; [email-masked]
Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Googling

     "sip/2.0" reason "q.850"

Dale

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 07:59:30 +0200

Thank you Dale for your input.
I have changed the Abstract.

BR,

Roland 

-----Ursprüngliche Nachricht-----
Von: Dale Worley [mailto:[email-masked]] 
Gesendet: Donnerstag, 16. Juli 2009 19:01
An: Jesske, Roland
Cc: [email-masked]; [email-masked]
Betreff: Re: AW: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

That clarifies things.

        
Dale

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 08:09:41 +0200

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:[email-masked]] 
Gesendet: Donnerstag, 16. Juli 2009 18:48
An: Jesske, Roland; Dale Worley
Cc: [email-masked]
Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Hi Roland,

RFC 3326 says in 1.0:

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 08:33:21 +0200

Hi,
With regard to Keith's answer I see that the draft is needed.
But where should this be done?

BLISS, DISPATCH or SIPCORE?

We have now the discussion within DISPATCH due to the fact that the draft was issued for the sipping group.

The issue shall solve interoperability problems with the PSTN where Q.850 causes shall be transferred through SIP.
An other used case is where applications within SIP networks could interpret the Reason header to put an announcement towards a user. This is important within Hybrid networks where SIP and ISUP runs in parallel.

Seen from this point of view the work should be done within BLISS to solve this interoperability problem.

RFC3326 was done within SIP and the draft could be seen as an extension to this RFC so that could be a reason to do this within SIPCORE.

Or the discussion takes place within DISPATCH and the draft was brought to SIPPING.

So how to proceed?

BR

Roland

-----Ursprüngliche Nachricht-----
Von: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Gesendet: Donnerstag, 16. Juli 2009 20:30
An: Francois Audet; Dale Worley
Cc: [email-masked]; Jesske, Roland
Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

regards

Keith

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 17 Jul 2009 10:07:43 -0500

Hi Roland,

I think DISPATCH remains the appropriate place for these discussions.  If we did agree specific changes to RFC 3326, that work would not fall under the charter of SIPCORE (as it's currently scoped as I understand it).  

It's not clear to me that this fits the scope of BLISS in that the focus of this document is on the clarifications to RFC 3326 to support certain services/environments.  It's not under the purview of BLISS to make SIP protocol changes.  [I will note that the BLISS charter needs to be updated to reflect how it does interface with SIPCORE and DISPATCH, rather than SIP and SIPPING as it's currently stated.]  I do see that more details of services that would need this reason header might fall into the BLISS WG charter.

My suggestion is that you update the document to incorporate the conclusions of this discussion ( the doc is currently expired) - you'll have to wait for the document submissions to be opened again on July 27th.  In my view, the crux of a work item is whether you need a true update to RFC 3326 or whether you are documenting clarifications  - similar to the sip-offeranswer document in SIPPING.  

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 17, 2009 1:33 AM
To: [email-masked]; Audet, Francois (SC100:3055); Worley, Dale (BL60:9D30)
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Hi,

So how to proceed?

BR

Roland

-----Ursprüngliche Nachricht-----
Von: DRAGE, Keith (Keith) [mailto:[email-masked]]
Gesendet: Donnerstag, 16. Juli 2009 20:30
An: Francois Audet; Dale Worley
Cc: [email-masked]; Jesske, Roland
Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

regards

Keith

> I believe the wishy-washy text about "status code explicitly allowing 
> it" was meant to exclude responses that were not appropriate, and 
> restricing it to effectively error responses.
>

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 17 Jul 2009 14:00:37 -0400

Thinking about this discussion, I would add a sentence to the abstract
telling the reader that the Reason header in responses is widely used,
even though it is not officially specified.  Something along these
lines:

        Although the use of the Reason header field in responses is
        considered in RFC 3326, doing so is not specified for any
        existing response code.  Nonetheless, the Reason header field
        has been widely used in responses to carry Q.850 reason codes
        for failure responses to INVITEs that have been gatewayed to
        PSTN systems.  This document specifies and formally permits the
        use of the Reason header field in SIP responses to carry Q.850
        reason codes for this and other purposes.

I think that makes the current situation clear to the uninformed reader
(e.g., me), and it only requires 3 sentences.

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 20 Jul 2009 12:40:37 +0300

Hi,

as Francois suggests, a document specifying the use of Reason header 
fields in responses needs to specify those things (see Francois' list 
below). Additionally, you should think of whether or not Reason header 
fields in responses can carry SIP status codes and what happens if they 
are different to the status code of the response.

In short, the document cannot simply say that now it is OK to use Reason 
in responses. It needs to address the different situations a typical 
implementation may face.

Cheers,

Gonzalo

---

From: <[email-masked]>
Date: Tue, 21 Jul 2009 07:03:10 +0200

Hi Gonzalo,
Thank you for your comments.
You are correct. The used cases within the document shows where ISUP causes will be included.
I think in such cases we should clearly state that SIP Reason should be excluded within SIP responses, to avoid contradictions. 

Then I will include that only within 4xx/5xx/6xx Responses the Reason header with an Q.850 Cause makes sense.

There are requirements and three used cases described within the draft so I hope that fits. 

Best Regards

Roland
-----Ursprüngliche Nachricht-----
Von: Gonzalo Camarillo [mailto:[email-masked]] 
Gesendet: Montag, 20. Juli 2009 11:41
An: Francois Audet
Cc: Dale Worley; [email-masked]; Jesske, Roland
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Hi,

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jul 2009 10:53:22 +0300

Hi,

yes, it is normal that the draft has focused on requirements and use 
cases so far. Once (or if) folks agree with those, we have to make sure 
that the normative behavior we define is correct and covers most typical 
cases.

Thanks,

Gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 12:34:14 -0500

and explain why 3XX, 2XX and 1XX don't make sense. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, July 20, 2009 22:03
> To: [email-masked]; Audet, Francois (SC100:3055)
> Cc: Worley, Dale (BL60:9D30); [email-masked]
> Subject: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04
> 
> Hi Gonzalo,
> I think in such cases we should clearly state that SIP Reason 
> should be excluded within SIP responses, to avoid contradictions. 
> 
> Then I will include that only within 4xx/5xx/6xx Responses 
> the Reason header with an Q.850 Cause makes sense.
> 
> as Francois suggests, a document specifying the use of Reason 
> header fields in responses needs to specify those things (see 
> Francois' list below). Additionally, you should think of 
> whether or not Reason header fields in responses can carry 
> SIP status codes and what happens if they are different to 
> the status code of the response.
> 
> In short, the document cannot simply say that now it is OK to 
> use Reason in responses. It needs to address the different 
> situations a typical implementation may face.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> Francois Audet wrote:
> >> turns up numerous examples of SIP responses using the 
> Reason header 
> >> in the forbidden manner.
> >>