[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sipping] RE: Mapping ISUP/QSIG causes to SIP response codes
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.
> 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.
[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.
> > 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.
[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.
>
> > 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).
[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.
>
> > 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.
[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.
>
> > 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.
[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.
>
> > 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.
[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.
>
> > 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?
[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 (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