Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

From: "Elwell, John" <[email-masked]>
Date: Thu, 4 Feb 2010 15:16:57 +0100

Roland,

Another use case we have come across is where we receive from Q.931 during outgoing call establishment a Disconnect message indicating busy and a progress indicator saying there is an in-band announcement. This needs to be mapped to a SIP 183 response (include SDP answer if not already sent), rather than a final response, so that the caller can hear the announcement from PSTN. However, being able to indicate busy in the Reason header field would allow an appropriate display on the device.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 28 January 2010 07:16
> To: [email-masked]
> Subject: [dispatch] ISSUES on 
> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in 
> Responses
> 
> Dear all, 
> The discussion at the last IETF meeting due to the proposal 
> to use the reason header within responses where controversial.
> 
> I would like to start the discussion on mentioned concerns. 
> 
> One concern was that we define an new encapsulation mechanism 
> for ISUP elements in parallel to SIP-T. 
> 
> The Reason header itself is a SIP generic Header defined in RFC3326. 
> 
> The syntax allows to put in a SIP Response code and/or an 
> ISUP Q.850 Cause Code. 
> 
> As many times mentioned before RFC 3326 (The Reason Header 
> Field for the Session Initiation Protocol (SIP)) defines the 
> following.
> 
>    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. 
> 
>    Note that the Reason header field is usually not needed in 
> responses 
>    because the status code and the reason phrase already provide 
>    sufficient information. 
> 
>    Clients and servers are free to ignore this header field.  
> It has no 
>    impact on protocol processing. 
> 
> At that time where RFC3326 was written it was not assumed 
> that a Reason in a response is usually not needed but it does 
> not restrict the use of the Reason header within responses. 
> It allows the use of the Reason header if the status code allows it.
> 
> That was the reasoning for writing this draft to allow the 
> Reason header within Responses and it is not an new 
> encapsulation mechanism.
> 
> Kind regards 
> Roland Jesske 
> 
> 
> Deutsche Telekom Netzproduktion GmbH 
> Technical Engineering Center 
> Roland Jesske 
> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt, Germany 
> +49 6151 628-2766 (Phone) 
> +49 521 9210-3753  (Fax) 
> +49 171 8618-445  (Mobile) 
> E-Mail: [email-masked] <mailto:[email-masked]>  
> www.telekom.com <http:www.telekom.com>  
> 
> Life is for sharing. 
> 
> Deutsche Telekom Netzproduktion GmbH 
> Supervisory Board: Dr. Steffen Roehn (Chairman) 
> Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert 
> Matheis, Klaus Peren 
> Commercial register: Local court Bonn HRB 14190 
> Registered office: Bonn 
> VAT identification no. DE 814645262 
> 
>