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

From: "Elwell, John" <[email-masked]>
Date: Tue, 18 Jun 2002 14:59:36 +0100

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 ([email-masked])
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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jun 2002 11:25:47 -0400

We've been working on the ISUP draft for quite some time now. By far,
the area that has received the most comments is the section on cause
code mapping. We've gone through massive contortions in an attempt
to make everyone involved as happy as possible. In fact, I doubt
there's a single status code left for which someone hasn't proposed
a change (and, for the most part, every time we changed a mapping to
make one person happy, two others would stand up and tell us why
they think the change was wrong). Any changes made at this point
without good technical reasons will almost certainly cause at least
one other person to become quite unhappy.

We'd still be happy to hear of honest-to-goodness bugs in the mapping
(e.g. "cause code x mapping to SIP y will make the UAC act in this
fashion, which leads to the demonstratably bad side effect of...").

At this point in the draft's life, however, philosophical arguments
(e.g. "I think 480 is better than 500, although can't quite quantify
what goes wrong if you use a 500") aren't of much value.

That said, I've attempted to explain my understanding of why certain
status code mappings were chosen instead of others below.

Finally, I appreciate the attempts to align the QSIG work with the ISUP
work. I do feel compelled to point out, however, that it seems more
appropriate that such alignment would largely cause a relatively new,
individual draft to change to come in line with a three-year-old
chartered working group item that has almost finished last call, rather
than the other way around.

/a

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
>
> codes in the 5xx group.

In general, though, these error codes represent some problem in the
switching fabric, not a problem with the called user or the request.
In terms of how they should be handled and interpreted by a SIP
end point, 500 is the closest fit.

> error" for miscellaneous Q.850 causes?

This is a very dangerous path that we chose not to pursue. From a precedent
point of view, the idea of adding ISUP-specific extensions to SIP paves
the way for subsuming complete chunks of ISUP into SIP. This is not our
goal. Further, since this is an informational draft, we cannot make
normative
additions to the protocol (such as new status codes).

> appropriate to map cause 5 to 404?

My understanding is that cause 5 would only be caused by a
misconfiguration at the gateway, while 1 can be caused by user error.
Correct me if I'm wrong.

> possible to generate a contact, and therefore cause 301 

No; a contact can be generated. Implementations need to be
flexible enough to allow customization to allow for variations
in the diagnostic field. As you point out, Q.850 doesn't standardize
this, which is precisely why we don't talk about the mechanism for
creating a Contact -- it may vary on a network-to-network basis.

> facility that is not authorized. Would 403 (forbidden) be better?

The authorization you're talking about isn't the same thing as
the "authorization" that 403 implies. 403 is used to indicate
that the *user* doesn't have permission to issue the request in
question. 50 (if my understanding is correct) indicates that the
operator agreements aren't in place. I don't think the situation
is analogous at all.

> 500, or 480 as proposed above). What about 501 (not implemented)?

Did you even check to see what 501 really means before you proposed
that?

> The
> the server (gateway) itself, which is not the case here.

It's important to think of how these codes are handled at the
UAC. If it's a problem in the network somewhere, it needs to be
a 5xx message -- which, in some circumstatnces, will cause
a failover to another server. That's exactly the sort of
behavior we need to resolve these types of problems.

4xx indicates some problem with the request itself,
and 6xx indicates some authoritative problem contacting the
user. Neither 4xx or 6xx are appropriate for network errors.

> appropriate, in line with the rest of the causes in the range 96..111.

Once again, it's important that the status code have the appropriate
effect at the UAC. In this case, the UAC needs to know that a node
in the network has timed out. It doesn't even necessarily know about
the existance of the ISUP network, so it couldn't possibly care
which network timed out.

In particular, this situation (receipt of a REL with cause 102) is
completely analogous to the case in which a SIP proxy receives a
504 response. What does it do? Well, it proxies the 504, of course.
It didn't time out itself, a node downstream did -- but it's *still*
sending a 504.

/a

---

From: [email-masked]
Date: Tue, 18 Jun 2002 14:07:59 EDT

> fashion, which leads to the demonstratably bad side effect of...").

[MAP] A problem for ISUP to SIP mapping (and back to ISUP) is that several 
ISUP cause codes (1, 2, and 3) are mapped to 404 which then gets mapped back 
to 1. This would mean that information is lost in this case of ISUP-SIP-ISUP 
interworking. This could prevent an originating side from playing an 
appropriate message. The philosophy should be that ISUP/ISDN did a lot of 
work to define the necessary set of cause codes, and all that apply should 
all be carried through SIP unchanged.

> misconfiguration at the gateway, while 1 can be caused by user error.

[MAP] I have a hard time imagining a case in which this cause code would be 
needed in the ISUP to SIP mapping. It reflects an error made by the 
originator in the local dailing plan. If there is a case, then it should be 
transferred into SIP without loosing its meaning.

The comments seem to address a number of cases in which there would be an 
ambiguity of whether an error occurred in the destination PSTN or in the 
gateway to the PSTN. Unless there is a clear distinction between the two, 
then there is a serious problem. Will it be possible to say, for every 
response that the originating side (UAC or originating proxy) receives, 
whether it was the result of an error in the PSTN or in the gateway?

Mike Pierce
Artel

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jun 2002 16:04:21 -0400

Please send plain text. Not everyone has the ability to read
HTML or Rich-Text formatted e-mail.

And it's a pain to reply to.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

>[MAP] A problem for ISUP to SIP mapping (and back to ISUP) is that
> several ISUP cause codes (1, 2, and 3) are mapped to 404 which
> then gets mapped back to 1. This would mean that information is
> lost in this case of ISUP-SIP-ISUP interworking. This could prevent
> an originating side from playing an appropriate message. The
> philosophy should be that ISUP/ISDN did a lot of work to define
> the necessary set of cause codes, and all that apply should all
> be carried through SIP unchanged.  

You have touched quite squarely on the motivation for carrying
ISUP bodies in SIP messages. If you're going to press for a
one-to-one mapping between ISUP cause codes and SIP response
codes, you've got a long battle ahead of you. I suggest reading
Don Quixote in preparation for your battle.

> The comments seem to address a number of cases in which there
> would be an ambiguity of whether an error occurred in the
> destination PSTN or in the gateway to the PSTN. Unless there
> is a clear distinction between the two, then there is a serious
> problem. Will it be possible to say, for every response that the
> originating side (UAC or originating proxy) receives, whether
> it was the result of an error in the PSTN or in the gateway? 

From the perspective of the UAC, it cannot -- MUST not, in fact,
matter whether the error occured in the PSTN or in the SIP network.
What matters is that the recovery actions taken upon receipt of that
error make sense in light of what has occured.

From a network diagnostics perspective, you are correct: you need
to be able to tell where something went wrong so that you can track
down and correct the problem. This is fundimentally an OAM&P issue,
and does not show up in the mapping of response codes.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Jun 2002 11:24:37 +0100

Adam,

Thanks for your detailed response, which is quite helpful in throwing light
on some of the principles adopted by you and the SIPPING group in arriving
at the current set of ISUP cause mappings. Without this understanding, it is
very difficult to proceed with confidence in aligning the SIP-QSIG draft.
See my detailed responses below.

> than the other way around.

[JRE] I take the point. One difficulty in trying to achieve alignment is
that some of the cause descriptions in Q.850 are open to different
interpretations. I guess the ISUP people had their own interpretations or
intentions when Q.850 was produced, and the QSIG people interpreted Q.850 in
a way that seemed to fit QSIG. This might have led to slightly different
uses in QSIG compared with ISUP, and this in turn seems to have led to
different ideas on how to map to SIP response codes. For example, cause 102
(recovery on timer expiry) is used in QSIG only for sending to the QSIG node
that has failed to send the expected message. If the rest of the call is
cleared as a result, QSIG uses cause 41. This is because it seemed
unreasonable to indicate a protocol error to a QSIG node that was not
responsible for that error.

> end point, 500 is the closest fit.

[JRE] My proposal for using 480 as a default was that it's description
seemed to fit (if you treat the ISUP network as the callee). However,
looking again at the meaning of the 4xx group, I can see that in general the
4xx group is not appropriate for most Q.850 causes, since they do not
represent an error with the particular request. It is in fact rather
surprising that 480 is in the 4xx group, since the description seems to
indicate a problem with the callee's end system, not with the original
request. But one could say the same about 486 and 488. It seems to be a fine
line between what is considered a request error and what is considered a
server error.

> additions to the protocol (such as new status codes).

[JRE] No, but a new code could have been defined in RFC3261. Also my
proposal was not for an ISUP-specific extension - it was for a very generic
"SCN error" (or perhaps "interworking error") response code.

> misconfiguration at the gateway, while 1 can be caused by user error.

[JRE] Because this is for national use, I am not sure how it is used in
practice. We would not use it in QSIG, apart from passing it on if we
received it from a public ISDN. So I accept your reasoning.

> creating a Contact -- it may vary on a network-to-network basis.

[JRE] So perhaps the SIP-ISUP draft should make it clear that 410 should be
used unless a diagnostic is received in a form that can be mapped to a
contact header.

> operator agreements aren't in place. I don't think the situation

[JRE] The description of cause 50 in Q.850 talks about a supplementary
service "..which the user is not authorized to use." So it seems to be a
problem with the user request, and a 4xx response code would seem to be
required.

> Did you even check to see what 501 really means before you proposed

[JRE] Yes, I did check. I interpreted (perhaps wrongly) that the text about
using 501 to reject an unrecognized method was one example of its use. If
this is intended to be the only circumstance in which 501 is to be used,
then I agree that 501 would be inappropriate for mapping this cause.

--------------------------------------------------------------
John Elwell ([email-masked])
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.