[Sipping] Mapping ISUP/QSIG causes to SIP response codes

["Elwell, John" <John.Elwell@siemenscomms.co.uk>]

In the interests of alignment, the authors of
draft-elwell-sipping-qsig2sip-00 have carried out a comparison of cause
mappings with those in draft-ietf-sipping-isup-02. As a result we have some
comments on mappings from ISUP causes to SIP response codes, as detailed in
6.2.4.1 of that draft.

Default mapping. The default response code for any causes not listed is 500
(server error). This implies an error in the SIP server, i.e., in the
gateway. This is misleading, since the error / rejection actually originated
within the ISUP network, i.e., at some signalling point beyond the gateway.
The server itself is not in error. This reasoning precludes all response
codes in the 5xx group. Also the 6xx group is not appropriate, since this
would prevent a proxy trying alternative destinations, which may work. This
leaves the 4xx group. Most codes in this group are very specific, but cause
480 (temporarily unavailable) is slightly more general. Unfortunately 480
means that the callee's endsystem has been contacted but the callee is
currently unavailable. For many Q.850 causes for which we need a default
mapping the callee's endsystem may not have been contacted, so this would be
a slight abuse of 480. But this still seems to be a better solution than
using a 5xx response. So we think 480 would be a more appropriate default
than 500. In the comments below on specific cause values, we have assumed
the use of 480 as the default where no other mapping seems appropriate. Note
that the reason phrase could indicate the Q.850 cause number to assist
diagnosis.
We also considered the use of response code 502 (bad gateway). The
description of this is "The server, while acting as a gateway or proxy,
received an invalid response from the downstream server it accessed in
attempting to fulfil the request". This is rather strange, because it is in
the 5xx group, yet the server itself is not in error - it is the downstream
server (or in this case, the downstream ISUP signalling point) that has
produced the "unmappable" cause value. Also, in most cases, "unmappable"
causes are not actually errors on the part of an ISUP signalling point. So
for these reasons we are not particularly happy about using 502 as a
default. However, we propose it below for a couple of causes which would
indeed appear to be invalid in the context of establishing a basic call from
SIP to ISUP.
Finally, what about defining a new response code in the 4xx range "SCN
error" for miscellaneous Q.850 causes?

Protocol errors. For protocol errors (causes 96..111), 500 remains
appropriate, since these really do represent problems at the server
(gateway).

Cause 5 (misdialled trunk prefix). This would seem to be similar to cause 1
(unallocated number). Yet cause 5 maps to the default response code
(currently 500) whereas cause 1 maps to 404 (not found). Would it not be
appropriate to map cause 5 to 404?
Cause 22 (number changed). This maps to 301 (moved permanently) if there is
a diagnostic present or 410 (gone) otherwise. Although Q.850 specifies a
diagnostic for optional use with cause 22, it does not detail how this
diagnostic is coded. In order to map to cause 301, a contact needs to be
supplied. If the coding of the diagnostic is not standardized, it is not
possible to generate a contact, and therefore cause 301 cannot be used.
Therefore it would seem that 410 has to be used on all occasions.
Cause 23 (redirection to new destination). This maps to 302 (moved
temporarily), which requires a contact. It is not clear where this would
come from, since no diagnostic is specified for cause 23. Also there is
nothing in the description of cause 23 to suggest that the redirection is
temporary. Reason code 410 (gone) seems more appropriate.
Cause 26 (non-selected user clearing). This maps to 404 (not found). Cause
26 is used on an access to clear an incoming call to user equipment if some
other equipment on the access has already responded positively to a
broadcast SETUP message. It has local significance on an access and should
not occur in a network signalling protocol such as ISUP. Also it occurs in
the downstream direction, not upstream. Response code 502 would seem to be
appropriate for this invalid situation, since the equipment downstream of
the gateway (the next ISUP signalling point) has behaved in an invalid
manner.
27 (destination out of order). This maps to 502 (bad gateway). However, that
response code seems too generic and seems to imply an invalid response from
an ISUP signalling point rather than a fault at the destination terminal.
Response code 480 (temporarily unavailable) would appear to be much more
appropriate.
29 (Facility rejected). This maps to 480 (temporarily unavailable). The
meaning of 480 is that the callee's endsystem was successfully contacted,
but the callee was not necessarily unavailable. Cause 29 means that a
supplementary service was rejected, which should not normally occur when
establishing a basic call from SIP to ISUP. Therefore 502 (bad gateway)
seems more appropriate.
31 (Normal, unspecified). This maps to 480 (temporarily unavailable). This
is fine, provided 480 is the default - see above. If a different default is
selected, cause 31 should map to that default.
38 (network out of order). This maps to 503 (service unavailable). The
meaning of 503 is temporary overload or maintenance of the server. On the
other hand, cause 38 is for a condition that "is likely to last a relatively
long period of time; e.g. immediately re-attempting the call is not likely
to be successful." Therefore 503 does not seem entirely appropriate.
However, there does not appear to be a better solution. The default proposed
above (480) also suggests a temporary condition.
44 (requested circuit/channel not available). This uses the default mapping
(500 at present, 480 according to argument above). However, this is another
case of congestion, arising from lack of circuit/channel somewhere in the
ISUP network. Mapping to 503 (service unavailable), in line with causes 42,
47, etc., would seem more appropriate.
49 (quality of service not available). This maps to the default. Because it
appears in group 48..63, this cause would suggest a service or option not
available. The reason it is not available is unclear, but if it were due to
temporary lack of resources, group 32..48 would be more appropriate. The
fact it is in group 48..63 seems to suggest barring, in which case response
code 403 (forbidden) would be appropriate. See also cause 63 below.
50 (requested facility not subscribed). This maps to 503 (Service
unavailable). Firstly, 503 suggests a temporary lack of resources, which is
not the case for cause 50. Secondly, cause 50 means an attempt to use a
facility that is not authorized. Would 403 (forbidden) be better?
53 (outgoing calls barred within CUG). This maps to the default (currently
500). Again this is an attempt to do something that is not authorized. Would
403 (forbidden) be better (in line with the treatment of cause 55)?
63 (service or option unavailable, unspecified). This maps to the default
(currently 500, or 480 as proposed above). Since most causes in group 48..63
relate to barred services, the use of 403 (forbidden) may be more accurate
than the default.
69 (requested facility not implemented). This maps to the default (currently
500, or 480 as proposed above). What about 501 (not implemented)? The
problem with all codes in the 5xx range is that they suggest an error with
the server (gateway) itself, which is not the case here. However, if we
ignore this, 501 seems quite appropriate (c.f. causes 65, 79).
70 (only restricted digital information available). Same comment as for 69.
87 (user not a member of a CUG). This maps to 503 (service unavailable).
However, it is not a temporary overload or maintenance condition. Code 403
(forbidden) would be appropriate.
88 (incompatible destination). This maps to 503 (service unavailable).
However, it is not a temporary overload or maintenance condition. It means
that the ISUP bearer capability and/or other compatibility parameters are
not acceptable to the called user. These parameters are derived from the
media type contained in SDP. Therefore 488 (not acceptable here) would seem
to be more appropriate.
102 (recovery on timer expiry). This maps to 504 (server time-out). This
implies the gateway has timed out, which is incorrect. In fact, the ISUP
signalling point beyond the gateway has timed out, perhaps because of an
error at the gateway. Therefore 500 (server internal error) would be more
appropriate, in line with the rest of the causes in the range 96..111.
--------------------------------------------------------------
John Elwell (john.elwell@siemens.com)
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the contents
of this message. Any views or opinions presented are solely those of the
author and do not necessarily represent those of Siemens Communications
Limited unless otherwise specifically stated.




_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP