Subject: Re: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03

From: Sumit Garg <[email-masked]>
Date: Thu, 26 Jun 2008 14:10:51 -0700 (PDT)

In the Intro for RFC3326 puts a restriction which says it can appear in any response whose status code explicitly allows this. This in fact is a needless restriction which causes the confusion. Any entity which does not support the header in the response can just ingore the header.
An amendment to 3326 could remove this restriction and then we probably don't need the draft.

from the RFC:
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.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
-- George Bernard Shaw

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeroen van Bemmel
Sent: Thursday, June 26, 2008 4:29 PM
To: Mary Barnes
Cc: [email-masked]
Subject: Re: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03

Roland,

RFC3326 (Reason header) already allows the use of the Reason header in 
responses, with Q.850 values. Your draft contains no requirements (as 
far as I see) which could not be addressed using existing standards, or 
am I missing something?

It does contain a security issue: in section 7 you state that "it is 
RECOMMENDED to include the Reason header information in Responses only 
by trusted entities", but the entity receiving the Reason header in a 
response has no way to authenticate the sender. Therefore, services 
shouldn't rely too heavily on this cause value (I guess playing a 
specific announcement is relatively harmless, but I wouldn't suggest to 
base charging on it for example)

Finally, I believe your third use case (playing a specific announcement) 
would be better implemented using an Error-Info header in the response, 
rather than a cause code out of a limited set. This would allow much 
more freedom in delivering meaningful announcements to users. Gateways 
could map specific URIs back to cause codes if needed, because in 
general SIP AS won't know or generate such Q.850 cause codes

Regards,
Jeroen

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 26 Jun 2008 23:43:46 +0200

Yes it is currently not allowed in responses, and to allow it in any
responses requires a standards track RFC ultimately produced by the SIP
group.

Which is where this thread is leading because SIP needs some
requirements produced by another group to generate such an RFC.

I would note that RFC 3326 already contains some pretty clear statements
as to why it was considered useful in requests and not in responses, and
there was a real concern in the WG at the time this was defined that
people would start sending Q.850 responses to end user terminals in a
Reason header rather than defining and using appropriate SIP response
codes.

So if you think that is wrong, now is the time, and this is the thread,
to identify the use cases where you think it is appropriate to put a
Reason header in a response.

I understand that at least one of the use cases required by the authors
is PSTN gateway to PSTN gateway in a scenario where SIP-I is not
appropriate. This use case obviously does not deliver the contents of
the Reason header (a Q.850 cause code) in the absence of anything more
SIP like. It is the Q.850 values that are needed transparently from one
end to the other in this case.

However part of this discussion should also look at whether we need more
SIP response codes as a solution to the other half of the problem.

And the document could do with drafting some real requirements that do
not assume a solution, even if there is a proposed solution in the same
document.

For example, under what circumstances does a initiating SIP terminal
that happens to be communicating with a PSTN gateway need to distinguish
the following values (given in the draft):

      34 no circuit available                 503 Service unavailable 
      38 network out of order                 503 Service unavailable 
      41 temporary failure                    503 Service unavailable 
      42 switching equipment congestion       503 Service unavailable 
      47 resource unavailable                 503 Service unavailable 
      58 bearer capability not presently      503 Service unavailable 
         Available 
      88 incompatible destination             503 Service unavailable 
    
      18 no user responding                   408 Request Timeout 

If we start understanding that we might be opening up an appropriate
discussion.

Regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sumit Garg
> Sent: Thursday, June 26, 2008 10:11 PM
> To: [email-masked]
> Cc: [email-masked]
> In the Intro for RFC3326 puts a restriction which says it can 
> appear in any response whose status code explicitly allows 
> this. This in fact is a needless restriction which causes the 
> confusion. Any entity which does not support the header in 
> the response can just ingore the header.
> "The reasonable man adapts himself to the world; the 
> unreasonable one persists in trying to adapt the world to 
> himself. Therefore all progress depends on the unreasonable man."
> -- George Bernard Shaw
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jeroen van Bemmel
> RFC3326 (Reason header) already allows the use of the Reason 
> header in responses, with Q.850 values. Your draft contains 
> no requirements (as far as I see) which could not be 
> addressed using existing standards, or am I missing something?
> 
> It does contain a security issue: in section 7 you state that 
> "it is RECOMMENDED to include the Reason header information 
> in Responses only by trusted entities", but the entity 
> receiving the Reason header in a response has no way to 
> authenticate the sender. Therefore, services shouldn't rely 
> too heavily on this cause value (I guess playing a specific 
> announcement is relatively harmless, but I wouldn't suggest 
> to base charging on it for example)
> 
> Finally, I believe your third use case (playing a specific 
> announcement) would be better implemented using an Error-Info 
> header in the response, rather than a cause code out of a 
> limited set. This would allow much more freedom in delivering 
> meaningful announcements to users. Gateways could map 
> specific URIs back to cause codes if needed, because in 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 27 Jun 2008 00:39:36 +0200

Keith,
>       18 no user responding                   408 Request Timeout 
Firstly, the reason phrase could always be used to communicate the cause 
to the user behind the SIP terminal (e.g. for debugging network 
problems). So we're talking about cases where _an automaton_ would need 
to make a distinction.

I'm no expert on Q.850, but I found this description somewhere on 
Internet (e.g. here http://www.ahk.com/ISDN%20Cause%20Codes.pdf) for 
#88: "This cause indicates that the equipment sending this cause has 
received a request to establish a call that has low layer compatibility, 
high layer compatibility or other compatibility attributes (for example, 
data rate), which cannot be accommodated.". On the surface this sounds 
to me better mapped on 488 Not Acceptable Here, as it is not a temporary 
condition like the other ones. (I guess this is a potential issue for 
RFC3398 though, not this draft)

The other mappings all seem appropriate. The gateway could use different 
retry-after values for the various causes, depending on how long they 
statistically last, but other than that I see no reason why a general 
SIP terminal would care.

Regards,
Jeroen

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 27 Jun 2008 10:45:05 +0200

Dear Keith,

> If we start understanding that we might be opening up an appropriate

1. is the transit scenarios from PSTN - SIP  back to PSTN without using
SIP-I.
So the PSTN on the other side needs proper information with regard to
the cause value, because the PSTN will put tones and announcements
towards the originating user. 

So for our network we have to different tones put towards the
originating user distinguishing if there is no circuit available or if
the switches are congested. And temporary failure is a totally different
one.

For completion we should show the whole (Mapping back):

   The mapping back is shown as follows: 
    
      Response received                        Cause value in the REL 
      -----------------                        ---------------------- 
      503 Service unavailable                  41 Temporary failure 
       
      408 Request timeout                      102 Recovery on timer  
                                                   expiry

So the mapping back will narrow down the information sent back and also
the user behaviour in hearing a wrong tone.

2. The second case is when we are migrating customers to SIP and would
like to give them the  same user expirience we would also like to have a
Application Server that can put in tones and announcements based on the
Reason header.

Best Regards

Roland

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Jun 2008 17:23:10 +0200

Hi,

Use-cases are always useful, but I am not sure what actual requirements we would actually need for this. I see it more as removing a unecessary restriction which seems to be based purely on "fear" of people using the Reason header instead of defining SIP response codes...

We support the draft.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeroen van Bemmel
Sent: 27. kesäkuuta 2008 1:40
To: DRAGE, Keith (Keith)
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03

Keith,
> that happens to be communicating with a PSTN gateway need to 
> distinguish the following values (given in the draft):
>
Firstly, the reason phrase could always be used to communicate the cause to the user behind the SIP terminal (e.g. for debugging network problems). So we're talking about cases where _an automaton_ would need to make a distinction.

I'm no expert on Q.850, but I found this description somewhere on Internet (e.g. here http://www.ahk.com/ISDN%20Cause%20Codes.pdf) for
#88: "This cause indicates that the equipment sending this cause has received a request to establish a call that has low layer compatibility, high layer compatibility or other compatibility attributes (for example, data rate), which cannot be accommodated.". On the surface this sounds to me better mapped on 488 Not Acceptable Here, as it is not a temporary condition like the other ones. (I guess this is a potential issue for
RFC3398 though, not this draft)

The other mappings all seem appropriate. The gateway could use different retry-after values for the various causes, depending on how long they statistically last, but other than that I see no reason why a general SIP terminal would care.

Regards,
Jeroen

This list is for NEW development of the application of SIP Use [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 30 Jun 2008 09:49:06 +0200

You appear to:

1)	Be dismissing concerns that were written into the original RFC without making any technical argument for their dismissal. These concerns are in an RFC, and that puts them on the same status level as all the other rules that IETF works from.

2)	Answering the question that has not yet been asked. Ultimately the SIP group has to endorse the solution proposed here, and it has to do that on the basis of information coming from the SIPPING group. Moreover the question the SIP group needs to ask is: "Is this an appropriate way to extend SIP going forward", not "This solution is a valid solution to this particular problem". There may be other solutions. There may be other problems to which a more generic solution is applicable.

This stage of the process is to identify the information that the SIPPING group needs to give the SIP group.

Regards

Keith

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Friday, June 27, 2008 4:23 PM
> To: Jeroen van Bemmel; DRAGE, Keith (Keith)
> Subject: RE: [Sipping] Progress on 
> draft-jesske-sipping-etsi-ngn-reason-03
> 
> 
> Hi,
> 
> Use-cases are always useful, but I am not sure what actual 
> requirements we would actually need for this. I see it more 
> as removing a unecessary restriction which seems to be based 
> purely on "fear" of people using the Reason header instead of 
> defining SIP response codes...
> 
> We support the draft.
> 
> Regards,
> 
> Christer
> 
>  
> 
> Firstly, the reason phrase could always be used to 
> communicate the cause to the user behind the SIP terminal 
> (e.g. for debugging network problems). So we're talking about 
> cases where _an automaton_ would need to make a distinction.
> 
> I'm no expert on Q.850, but I found this description 
> somewhere on Internet (e.g. here 
> http://www.ahk.com/ISDN%20Cause%20Codes.pdf) for
> #88: "This cause indicates that the equipment sending this 
> cause has received a request to establish a call that has low 
> layer compatibility, high layer compatibility or other 
> compatibility attributes (for example, data rate), which 
> cannot be accommodated.". On the surface this sounds to me 
> better mapped on 488 Not Acceptable Here, as it is not a 
> temporary condition like the other ones. (I guess this is a 
> potential issue for
> The other mappings all seem appropriate. The gateway could 
> use different retry-after values for the various causes, 
> depending on how long they statistically last, but other than 
> that I see no reason why a general SIP terminal would care.
> 
> Regards,
> Jeroen
> 
> 
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 30 Jun 2008 10:26:41 +0200

It is difficult to give technical argument against something which is based on "paranoia" :)
 
Seriously, I see this is a "bug", so why do we need technical requirements in order to fix that?
 
Regards,
 
Christer

________________________________

From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Mon 30/06/2008 09:49
To: Christer Holmberg; Jeroen van Bemmel
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] Progress on draft-jesske-sipping-etsi-ngn-reason-03

You appear to:

Regards

Keith

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 30 Jun 2008 14:10:37 +0200

SIP made a clear decision not to include Reason header in responses in the original RFC. There was no "bug" in the sense that something got documented that was not intended. The original RFC expresses the decision of the working group at that time.

Therefore please concentrate on filling the process in the correct way for an enhancement.

Regards

Keith

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Monday, June 30, 2008 9:27 AM
> To: DRAGE, Keith (Keith); Jeroen van Bemmel
> 1)      Be dismissing concerns that were written into the 
> original RFC without making any technical argument for their 
> dismissal. These concerns are in an RFC, and that puts them 
> on the same status level as all the other rules that IETF works from.
> 
> 2)      Answering the question that has not yet been asked. 
> Ultimately the SIP group has to endorse the solution proposed 
> here, and it has to do that on the basis of information 
> coming from the SIPPING group. Moreover the question the SIP 
> group needs to ask is: "Is this an appropriate way to extend 
> SIP going forward", not "This solution is a valid solution to 
> this particular problem". There may be other solutions. There 
> may be other problems to which a more generic solution is applicable.
> 
> This stage of the process is to identify the information that 
> the SIPPING group needs to give the SIP group.
> 
> Regards
> 
> Keith
> 
> 
> 
> > requirements we would actually need for this. I see it more as 
> > removing a unecessary restriction which seems to be based purely on 
> > "fear" of people using the Reason header instead of defining SIP 
> > response codes...
> >
> > We support the draft.
> >
> > Regards,
> >
> > Christer
> >
> > 
> >
> > Firstly, the reason phrase could always be used to communicate the 
> > cause to the user behind the SIP terminal (e.g. for 
> debugging network 
> > problems). So we're talking about cases where _an automaton_ would 
> > need to make a distinction.
> >
> > Internet (e.g. here
> cause has 
> > received a request to establish a call that has low layer 
> > compatibility, high layer compatibility or other compatibility 
> > attributes (for example, data rate), which cannot be 
> accommodated.". 
> > On the surface this sounds to me better mapped on 488 Not 
> Acceptable 
> > Here, as it is not a temporary condition like the other 
> ones. (I guess 
> > this is a potential issue for
> > The other mappings all seem appropriate. The gateway could use 
> > different retry-after values for the various causes, 
> depending on how 
> > long they statistically last, but other than that I see no 
> reason why 
> > a general SIP terminal would care.
> >
> > Regards,
> > Jeroen
> >
> >
> >
> >
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> >
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 30 Jun 2008 14:23:28 +0200

Hi,
 
I didn't mean that there would have been a documentation bug - I am sure we correctly documented the decission made at that time.
 
Regards,
 
Christer

Sent: Mon 30/06/2008 14:10

Regards

Keith