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

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

Further to recent discussion on mapping ISUP or QSIG causes to SIP response
codes, the authors of draft-elwell-sipping-qsig2sip-00 have carried out a
comparison of cause mappings in the opposite direction. As a result we have
some comments on mappings from SIP response codes to ISUP causes, as
detailed in 7.2.6.1 of draft-ietf-sipping-isup-02.
Default mapping. The default cause value for any response codes not listed
is 31 (normal, unspecified). An alternative would be 127 (interworking
unspecified). It is not clear what criteria should be used to judge that a
condition is "normal", whereas it is quite clear that we are interworking in
this situation. Was there any particular reason why 127 was not adopted as
the default?
Response codes 401 (unauthorized), 402 (payment required) and 403
(forbidden). These all map to cause 21 (call rejected). Cause 21 seems to
imply rejection by the user (or by the network in accordance with
instructions from the user). Cause group 48..63 seems to deal with cases
where a service or option is not available, in particular because it is
barred in some way. The particular cause 63 (service or option unavailable,
unspecified) would appear to be suitable for all these response codes. What
was the motivation for using cause 21?
Response code 404 (not found). This maps to cause 1(unallocated number). Was
there any particular reason for not using cause 3 (no route to destination),
which "indicates that the called party cannot be reached because the network
through which the call has been routed does not serve the destination
desired"?
Response code 405 (method not allowed). This maps to cause 63 (service or
option unavailable, unspecified). This response code does not really
indicate that a service or option requested by the ISUP network is
unavailable. It indicates a protocol error in the SIP network. Something
more general purpose (e.g., 127) would appear to be more appropriate.
Response code 406 (not acceptable). This maps to cause 79 (service or option
not implemented, unspecified). This response code does not really indicate
that a service or option requested by the ISUP network is unavailable. It
indicates that the SIP UAC (in this case the gateway) has included an Accept
header that is not acceptable to a downstream SIP entity. It is therefore an
internal problem within the SIP network. Something more general purpose
(e.g., 127, 38) would appear to be more appropriate.
Response code 407 (proxy authentication required). This maps to cause 21
(call rejected). Because this is similar to response code 401, according to
the argument above it would be more appropriate to map it to cause 63
(service or option unavailable, unspecified). Alternatively one could take
the view that proxy authentication is an internal matter of the SIP network
and that the response code should therefore map to cause 127 (interworking,
unspecified). What was the reasoning?
Response codes 408 (request timeout) and 504 (server time-out). These both
map to cause 102 (recovery on timer expiry). Response code 408 represents
protocol timeout in the SIP network, not in the ISUP network. Response code
504 means "the server did not receive a timely response from an external
server it accessed in attempting to process the request", which is an
internal problem within the SIP network and does not mean that the gateway
has timed out waiting for an ISUP message. In both cases, cause 102, which
belongs to the protocol error group (96..111) is misleading. Perhaps this is
a case of QSIG interpretations of cause values being different from ISUP
interpretations. We feel that cause 127 (interworking, unspecified) should
be used.
Response code 415 (unsupported media type). This maps to cause 79 (service
or option not implemented, unspecified). This response code does not really
indicate that a service or option requested by the ISUP network is not
implemented. It indicates that the SIP UAC has included a message body
format that is not acceptable to a downstream SIP entity. It is therefore an
internal problem within the SIP network and not the fault of the calling
user for requesting an unimplemented service. Something more general purpose
(e.g., 127) would appear to be more appropriate.
Response code 481 (call/transaction does not exist). This maps to cause 41
(temporary failure). This is an internal protocol problem within the SIP
network. Something more general purpose (e.g., 127) would appear to be more
appropriate.
Response codes 488 (not acceptable here) and 606 (not acceptable). In the
absence of a suitable warning code in the warning header, these map to the
default (currently 31, or 127 as suggested above). Because these response
codes indicate an unacceptable session description, cause 65 (bearer
capability not implemented) or 88 (incompatible destination) would seem to
be more appropriate. It is not clear which of these two should be used, but
either would be more specific than the default. They would give the calling
user an indication that he has requested a service that is not available at
the destination and might suggest to the user that he try again with a
different service.
Response codes 501 (not implemented) and 502 (bad gateway). These both map
to cause 38 (network out of order). There are lots of other SIP response
codes that suggest a problem within the SIP network, in particular some of
the 4xx codes that could arise because of the way the gateway has
constructed the SIP INVITE request (e.g., 400, 405, 406...). Cause 38 is not
used for any of these. What was the motivation for using cause 38 only for
501 and 502?

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