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

From: <[email-masked]>
Date: Mon, 7 Jul 2008 16:01:32 +0300

Keith,

you were asking about these different cause values that are considered
in the draft:

>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 

The above list contains values from "normal", "resource unavailable",
"service not available" and "invalid message" value range. 

Some of them are temporary, some are likely to remain permanent even
though a new attempt was made after a while. 

At least that is part of the information that is lost if we map e.g. #41
and #88 onto the same 503 Service unavailable. If it was between the
terminal and the serving network then as a user I for sure would like to
know whether a re-attempt has got any chances of success or not, but I
don't know if the gateway needs to be aware of this. Maybe the network
experts can clarify, please?

BR,
Hannu Hietalahti
3GPP CT chairman
Mobile phone: +358 40 5021724

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext DRAGE, Keith (Keith)
>Sent: 27 June, 2008 00:44
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [Sipping] Progress on 
>draft-jesske-sipping-etsi-ngn-reason-03
>
>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
>
>> -----Original Message-----
>> 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]
>> Subject: Re: [Sipping] Progress on
>> draft-jesske-sipping-etsi-ngn-reason-03
>> 
>> 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
>> 
>_______________________________________________
>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
>
_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Tue, 8 Jul 2008 09:54:35 +0200

Dear Hannu,
You are right the correct cause will give the user more information why the call was released. And as you said he knows if the call was released due to a temporary unavailability or a congestion the user can try it again. But if the requested Service is not available like Rel Cause 88 indicates it the user knows that either the destination cannot provide the service or his service was not correctly configured.

With regard to the crank back feature used within ISUP the following cause values will be used. 
*	27 destination out of order
*	34 no circuit available
*	38 network out of order
*	41 tempory failure
*	42 switching equipment congestion
*	47 resource unavailable, unspecified

But it is important that the location is a network location. From that point of view a re attempt on an other trunk will be done by the succeeding exchange but not beyond an interworking like it is when the call was passed through a SIP network. So normally a reattempt will be done before the interworking.
If the location would be part of the release cause such re attempt on an other ISUP way could also be possible after the passed SIP network.

Best regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von 
> [email-masked]
> Gesendet: Montag, 7. Juli 2008 15:02
> An: [email-masked]; [email-masked]; 
> [email-masked]
> Betreff: Re: [Sipping] Progress on

---

From: [email-masked]
Date: Tue, 8 Jul 2008 11:47:27 -0400

From: "Jesske, R" <[email-masked]>

   But it is important that the location is a network location. From
   that point of view a re attempt on an other trunk will be done by
   the succeeding exchange but not beyond an interworking like it is
   when the call was passed through a SIP network. So normally a
   reattempt will be done before the interworking.
   If the location would be part of the release cause such re attempt
   on an other ISUP way could also be possible after the passed SIP
   network.

I don't understand ISUP...  But does the above discussion imply that
we want the "location" value to be part of the information carried by
the feature that is the solution to these requirements?

Dale

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 11 Jul 2008 09:29:53 +0200

I don't see the need for definition of the location. I had this already within one of the drafts but due to comments I deleted it.

So if people wish to have also the location included I need the support.

The most important is to provide the cause value for the discussed scenarios.

Best Regards

Roland  

> [email-masked]
> Gesendet: Dienstag, 8. Juli 2008 17:47
> An: [email-masked]

---

From: [email-masked]
Date: Fri, 11 Jul 2008 15:51:16 -0400

I don't see the need for definition of the location. I had this
   already within one of the drafts but due to comments I deleted it.

I just looked at Q.850, and the "location" field distinguishes
failures at the remote user from failures in transit, which is what
we're looking for in draft-worley-redundancy-response-03:

    An increasing number of SIP architectures implement multiple path
    routing (MPR), which is the providing of more than one path for a
    call to reach a destination user agent (UA).  To implement MPR well,
    the proxy which forks a request onto the redundant paths needs to be
    able to determine if a fork that failed reached the destination UA
    and was rejected by the UA (and so an alternate path should not be
    tried), or if the fork failed before reaching the UA (and so an
    alternate path should be attempted).  This document is to begin a
    discussion of strategies for making this determination.

Dale