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

[Adam Roach <adam@dynamicsoft.com>]

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: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.

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.

> Finally, what about defining a new response code in the 4xx range "SCN
> 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).

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

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.

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

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.

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

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.

> 69 (requested facility not implemented). This maps to the 
> default (currently
> 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
> 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.

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.

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

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

_______________________________________________
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