Subject: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Interworking of Responses

From: <[email-masked]>
Date: Thu, 28 Jan 2010 11:38:38 +0100

Dear all,
The discussion about the use of the Reason header within responses was triggered by the used case where ISUP-SIP-ISUP traversal will happen without using SIP-T.
During the discussion at the last IETF meeting it was asked how the pure mapping of ISUP Cause to SIP Response and back will cause the ISUP network. Here is the consideration of this issue.

The case where a call will be released within a pure ISUP network it will cause a announcement based on  the ISUP Release Cause. 
When the call instead has to traverse a SIP network the ISUP cause will change in most of the cases and the related announcement. 

The figure below shows the principle of such a call ISUP-SIP-ISUP.

 Phone     PTSN SWITCH            Gateway A          Gateway B             B
   
 |               |                   |                  |                  |
 |  Setup Message|                   |                  |                  |
 |  Phone        |        IAM        |                  |                  |
 |-------------->|------------------>|     INVITE       |                  |
 |               |                   |----------------->|      IAM         |
 |               |                   |     100 Trying   |----------------->|
 |               |                   |<-----------------|    100 Trying    |
 |               |                   |   403 Forbidden  |                  |
 |               |                   |  Reason Q850 #87 |  REL Cause #87   |
 |  play         |   REL Cause #87   |                  |<-----------------|
 |  Announcement |                   |<-----------------|                  |
 |<--------------|<----------------- |                  |                  |
 |               |                   |                  |                  |
 |               |                   |                  |                  |
 |               |                   |                  |                  |

The table below shows now the mappings of the Cause and the relating announcements
Problem is that the mapping regarding RFC 3398 will result in the following table.

EXAMPLE: 
The Call is released with Cause 27 from the user B
This Cause will normally trigger an announcement B.

Due to the rules in ISUP the Announcement/Tone is put into the media path at the originating switch.

So the first gateway maps (RFC3398) the ISUP RELEASE message with Cause 27 to a SIP response 502 Bad Gateway

Now mapping back (RFC3398) to ISUP the release cause 38 will be taken and this Release Cause will trigger an congestion tone.

The following table shows now the mapping for our PSTN network and the corresponding announcements.  

         Mapping ISUP SIP  GW-B               Mapping SIP ISUP GW-A
         ------------------------>             ------------------> 
  
ISUP  Tone or                                         ISUP
CAUSE Announcement	       SIP Response                 CAUSE	Tone or Announcement

 1	ANNOUNC. A	       404 Not Found	             1	ANNOUNC. A
*2	ANNOUNC. C	       404 Not found	             1	ANNOUNC. A
 3	ANNOUNC. A   	 404 Not found	             1	ANNOUNC. A
 16	Congestion tone    --- (*)		 
 17	Busy Tone	       486 Busy here	            17	Busy tone
*18	Busy Tone     	 408 Request Timeout	      102	Congestion tone
 19	Busy Tone     	 480 Temporarily unavailable  18	Busy tone
*20	ANNOUNC. B	       480 Temporarily unavailable  18	Busy tone
 21	ANNOUNC. B	       403 Forbidden (+)	      21	ANNOUNC. B
 22	ANNOUNC. A	       410 Gone	                  22	ANNOUNC. A
*23	Congestion tone    410 Gone	                  22	ANNOUNC. A
*26	Congestion tone    404 Not Found (=)	       1	ANNOUNC. A

*27	ANNOUNC. B	       502 Bad Gateway	            38	Congestion tone

*28	Congestion tone	 484 Address incomplete	      28	Congestion tone
 29	ANNOUNC. D          501 Not implemented	      79	ANNOUNC. D
*31	Congestion tone    480 Temporarily unavailable	18	Busy tone
 34	Congestion tone    503 Service unavailable	41	Congestion tone 
 38	Congestion tone    503 Service unavailable	41	Congestion tone
 41	Congestion tone	 503 Service unavailable      41	Congestion tone
*42	ANNOUNC. B	       503 Service unavailable      41	Congestion tone
 47	Congestion tone	 503 Service unavailable      41	Congestion tone
*55	ANNOUNC. D	       403 Forbidden	            21	ANNOUNC. B
*57	ANNOUNC. D	       403 Forbidden	            21	ANNOUNC. B
 58	Congestion tone    503 Service unavailable      41	Congestion tone
*65	ANNOUNC. D	       488 Not Acceptable Here      127	Congestion tone  (**)  
*70	ANNOUNC. D	       488 Not Acceptable Here      127	Congestion tone  (**) 
 79	ANNOUNC. D	       501 Not implemented	      79	ANNOUNC. D
*87	ANNOUNC. D	       403 Forbidden	            21	ANNOUNC. B
*88	ANNOUNC. D	       503 Service unavailable      41	Congestion tone
 102	Congestion tone    504 Gateway timeout	      102	Congestion tone
*111	ANNOUNC. D	       500 Server internal error    41	Congestion tone
 127	Congestion tone    500 Server internal error    41	Congestion tone

(*) Announcement change due to passing the SIP domain
(**)No mapping in RFC 3398 described in the field 127 is used then as default mapping.

Half of the mapped Responses will end in a ISUP Cause that will initiate an other announcement than intended from the originator of the Release cause.

That is why a mapping of a Release Cause into an Reason Header and back to the ISUP cause will help in an easy using an existing SIP header that is intended to carry ISUP causes.

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]
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