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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Feb 2010 14:12:38 +0200

Hi,

talking as a chair, most of the discussions we had last time were about
using Reason in responses versus using encapsulated ISUP REL messages.
Some people claimed that REL messages are rather small and that the
overhead of both approaches would be comparable.

I suggest you try and address those concerns.

Thanks,

Gonzalo
DISPATCH co-chair

[email-masked] wrote:
> 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] <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
>