Subject: Re: [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2011 08:53:13 -0500

I've realized via discussions with Christer that the changes here are 
introducing a conflict with the 199 draft.

That draft is explicitly calling for use of a Reason header with sip 
cause code to indicate the final sip response that caused a 199 response 
to be sent.

Because 199 is being defined to explicitly allow this usage, it is in 
compliance with 3326. If we were to revise 3326 as we are discussing, 
then the 199 usage would be in conflict with the revision.

So, I think we have to craft the wording very carefully here, to allow 
the use of Q.850 codes in a range of responses, while leaving the use of 
sip reason codes up to per-response-code specifications, as it was.

And I'll restate that it probably doesn't make good sense to use any/all 
Q.850 response codes in an arbitrary sip response either.

	Thanks,
	Paul

On 1/31/2011 5:53 AM, [email-masked] wrote:
> Hi Paul,
> Thank you for the hint.
> Yes I agree that it would be a little seldom if a SIP reason code would be included within a SIP Response.
> So I tried to change the wording like:
>
> Section 3. New Text:
>
> 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, if it contains a Q.850 Cause Code,  except the 100 trying response.
>
> Section 4. New Text:
>
> The Reason header field containing a Q.850 Cause Code MAY appear in any request within a dialog, in any CANCEL request. The appearance of the Reason header is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x and 199
>
> So I hope now the document is more consistent.
>
> Best Regards
>
> Roland
>
>>
>
>> -----Ursprüngliche Nachricht-----
>> Von: [email-masked]
>> [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
>> Gesendet: Freitag, 28. Januar 2011 17:15
>> An: [email-masked]
>> Betreff: Re: [dispatch] Update fo RFC3326 or
>> draft-jesske-dispatch-reason-in-responses approach
>>
>>
>>
>> On 1/28/2011 8:11 AM, [email-masked] wrote:
>>> Hi Mary,
>>> until now it looked for me it is the decision of people
>> which way they
>>> want to go.
>>> So seeing from your mail I see that there an UPDATE to
>> RFC3326 would be
>>> more convenient and my other draft could help to have some
>> reasoning/use
>>> cases.
>>> So I have Uploaded an draft proposing an UPDATE to RFC3326.
>>>
>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason
>> -responses-00.txt
>>> Comments are welcome.
>>> Best Regards
>>> Roland
>>
>>
>> Its a very simple draft (which is fine).
>>
>> I do find an inconsistency. The overview states:
>>
>>      This document specifies and formally permits the use of the
>>      Reason header field in SIP responses to carry Q.850 [Q.850]reason
>>      codes for this and other purposes.
>>
>> But the actual normative changes permit *any* sort of reason codes in
>> responses.
>>
>> This could be especially confusing if a sip reason code is
>> included in a
>> sip response.
>>
>> Also, this says nothing about what it *means* to have a
>> reason code in a
>> response, while 3326 does say a bit about what it means to
>> put a Reason
>> in a request. In the case of Q.850 reasons its fairly
>> obvious, at least
>> coming from a Q.850 gateway.
>>
>> The simple answer here would be to exclude the use of SIP Reasons in
>> responses. Else there had better be text on when it is
>> appropriate. (And
>> I can't think of any.)
>>
>>        Thanks,
>>        Paul
>>
>>>
>> --------------------------------------------------------------
>> ----------
>>>      *Von:* Mary Barnes [mailto:[email-masked]]
>>>      *Gesendet:* Donnerstag, 27. Januar 2011 18:10
>>>      *An:* Jesske, Roland
>>>      *Cc:* [email-masked]
>>>      *Betreff:* Re: [dispatch] Update fo RFC3326 or
>>>      draft-jesske-dispatch-reason-in-responses approach
>>>
>>>      The problem is that the current wording in the draft implies an
>>>      update to RFC 3326 - i.e., it states:
>>>      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.
>>>
>>>
>>>      So, the question isn't whether to progress the draft per se but
>>>      whether the implication of the functionality you describe is a
>>>      normative change RFC 3326 (i.e., UPDATES) or whether an
>>>      informational draft is sufficient. I would posit that
>> if this work
>>>      is progressed as informational, then it should be restricted to
>>>      describing the use of SIP responses to carry the Q.850
>> reason codes
>>>      and drop the the "other purposes". And, you need to remove the
>>>      normative RFC 2119 language. In other words, if folks
>> do not believe
>>>      an update to RFC 3326 is necessary then the drafts needs to be
>>>      revised to limit the scope and be quite clear that it
>> is informational.
>>>
>>>      Regards,
>>>      Mary.
>>>
>>>      On Thu, Jan 27, 2011 at 10:31 AM,<[email-masked]
>>>      <mailto:[email-masked]>>  wrote:
>>>
>>>          So to clarify my opinion below.
>>>          used the wrong number.
>>>
>>>          As long as the draft is already existing I have my
>>>          preference to go for 2.
>>>
>>>          that is the problem using too easy numbering.
>>>
>>>          Sorry
>>>
>>>
>>>           >  -----Ursprüngliche Nachricht-----
>>>           >  Von: [email-masked]
>> <mailto:[email-masked]>
>>>           >  [mailto:[email-masked]
>>>          <mailto:[email-masked]>] Im Auftrag von
>> Jesske, Roland
>>>           >  Gesendet: Donnerstag, 27. Januar 2011 17:00
>>>           >  An: [email-masked]<mailto:[email-masked]>
>>>           >  Betreff: [dispatch] Update fo RFC3326 or
>>>           >  draft-jesske-dispatch-reason-in-responses approach
>>>           >
>>>           >
>>>           >  Dear all,
>>>           >  a couple of days we discussed how to proceed
>> with the reason
>>>           >  in responses.
>>>           >
>>>           >  As I see we have enough support for going ahead.
>> But which
>>>           >  approach should we take. (Mary asked this
>> question also on
>>>          Monday)
>>>           >
>>>           >  1. write an UPDATE to RFC 3326
>>>           >  2. progress draft-jesske-dispatch-reason-in-responses
>>>           >
>>>           >  Currently I have seen the following opinions:
>>>           >
>>>           >  For solution 1. +1 Paul
>>>           >  For solution 2. + Laura
>>>           >  1 or 2 don't mind +1 John
>>>           >
>>>           >  As long as the draft is already existing I would have my
>>>           >  preference to go for 1.
>>>           >  But if needed I can also create an UPDATE to RFC3326.
>>>           >
>>>           >  So please indicate your solution you would like to see.
>>>           >
>>>           >  Thank you and Best Regards
>>>           >
>>>           >  Roland
>>>           >  _______________________________________________
>>>           >  dispatch mailing list
>>>           >  [email-masked]<mailto:[email-masked]>
>>>           >  https://www.ietf.org/mailman/listinfo/dispatch
>>>           >
>>>          _______________________________________________
>>>          dispatch mailing list
>>>          [email-masked]<mailto:[email-masked]>
>>>          https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 1 Feb 2011 20:19:29 +0530

Hi Roland,
 
I agree to the point that Update of RFC 3326 is implemented by lot of
vendors as there is no proper mapping between Q.850 and SIP response.  I
noticed that Cisco PSTN (TDM) GW implemented reason header in SIP
response long back as there was no proper reverse mapping exists for
Q.850 from SIP response. The solution works well for PSTN---SIP----PSTN
topology. In case your intention of updating RFC 3326 is to create "Best
current practice" or "Historic" document, then I'm complete with you as
the legacy PSTN GW to SIP interop issue may be solved smoothly by your
draft reference. 
 
My concern (issues noticed) with UPDATE of RFC 3326 as Proposed Standard
are as follows:
 
1) In case of new implementation which acts as both B2BUA and PSTN
GW(SIP UA--PSTN) has to handle two response code for SIP responses as
standard mentions to handle two types response codes (Q.850 cause code,
SIP response code). This could be avoided in case single response code
method exist (which is update for RFC 3398). [Multiple type of response
code handled may be implemented in few of the existing implementation as
there is no solution exists]
 
2) The solution of passing Q.850 cause code *may* fail when B2BUAs are
involved in the topology. In real deployment, most of the solutions will
have multiple SIP (B2BUA) hops. So, the topology like PSTN
Cloud----SIP--B2BUA---SIP---PSTN cloud will not pass across reason
header as there is no means to enforce this policy of passing reason
header through B2BUA.  The point to be noted is that SIP response header
normally passed across well in B2BUA with proper translation (like 503
to 500) because it is related to RFC 3261. 
 
As your work looks like interworking between IMS SIP entity and PSTN
(NGN network to legacy), it may be preferred to have the proper SIP
based solution which translates PSTN cause code at PSTN-IMS GW itself.
Please let me know your opinion on the above concerns. Also in case you
address the above concerns, Please let me know the approach.
 
Thanks
Partha

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 31, 2011 6:50 PM
To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); [email-masked]
Subject: AW: [dispatch] Update fo
RFC3326ordraft-jesske-dispatch-reason-in-responses approach

Hi Partha,
A UPDATE to RFC3326 will reflect that what is already implemented all
over the world while a UPDATE to RFC 3398 will never succeed due to the
fact that the Q.850 CV are very different to SIP Responses.
 
There are groups of Q.850 Causes that are mapped to the same SIP
Response due to the fact that only one fit to such a Response. E.G
Response 503 is very often used for a couple of Q.850 causes. But the CV
itself causes within ISUP different reactions (e.G special Tones or
Announcements).
 
And as the reactions showed there is enough support for a further
progress to allow the Reason header (containing Q.850 Causes) within
responses. 
 
Best Regards
 
Roland
________________________________

Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Parthasarathi R (partr)
Gesendet: Freitag, 28. Januar 2011 17:51
An: Paul Kyzivat (pkyzivat); [email-masked]; Jesske, Roland
Betreff: Re: [dispatch] Update fo RFC3326
ordraft-jesske-dispatch-reason-in-responses approach

	Hi Roland,
	 
	Including Roland in this mail thread...
	 
	For your requirement, Update of RFC 3398 may solve the issue but
update of RFC 3326 is a workaround.
	 
	Please correct me in case I'm missing something.
	 
	Thanks
	Partha

________________________________

	From: [email-masked] on behalf of Parthasarathi R
(partr)
	Sent: Thu 1/27/2011 10:36 PM
	To: Paul Kyzivat (pkyzivat); [email-masked]
	Subject: Re: [dispatch] Update fo RFC3326
ordraft-jesske-dispatch-reason-in-responses approach

	Hi Roland,
	 
	I look into draft-jesske-dispatch-req-reason-in-responses-02
requirement. By reading your requirement document, it looks like that
RFC 3398 does not distinguish each of the Q.850 to SIP responses. It
leads to wrong response code in PSTN--SIP--PSTN topology. In case the
proper mapping exist between Q.850 to SIP response, the problem *may* be
solved. Pls correct me in case I misunderstand your requirement
document.
	 
	I agree that Q.850 cause code in SIP response solves the problem
for PSTN--SIP--PSTN network but ISTM protocol hack as there are two
response codes exist in the same response and the two response codes are
mutually exclusive in one occasion and different in other occasion.
	 
	Eg:  1) In single response msg, same response in two form 
	 
	   503 SIP msg response with 41 as Q.850 cause code
	 
	2) In single response msg, Different responses 
	  
	   503 SIP msg response with 34 as Q.850 cause code
	 
	This could be avoided in case the proper mapping exist. Please
let me know your opinion here.
	 
	Thanks
	Partha

________________________________

	From: [email-masked] on behalf of Paul Kyzivat
(pkyzivat)
	Sent: Thu 1/27/2011 10:33 PM
	To: [email-masked]
	Subject: Re: [dispatch] Update fo RFC3326 or
draft-jesske-dispatch-reason-in-responses approach

	I can live with either way.
	
	        Thanks,
	        Paul
	
	On 1/27/2011 11:00 AM, [email-masked] wrote:
	>
	> Dear all,
	> a couple of days we discussed how to proceed with the reason
in responses.
	>
	> As I see we have enough support for going ahead. But which
approach should we take. (Mary asked this question also on Monday)
preference to go for 1.