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

From: "Elwell, John" <[email-masked]>
Date: Tue, 02 Jul 2002 16:37:20 +0100

Jon,

My detailed responses are in-line.

Regards,

--------------------------------------------------------------
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.
> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 01 July 2002 13:17
> To: 'Elwell, John'
> Subject: RE: Mapping SIP response codes to ISUP/QSIG causes
> 
> 
> Hello John,
> 
> As I'm doing some updates in sipping-isup-02, I have a few 
> comments about
> your suggestions below (since Adam responded to the other half of your
> mapping suggestions).
> 
> Many of your suggestions beg the question of what a protocol 
> mapping is,
> exactly. One could argue that no SIP response code is exactly 
> coexistensive
> with any Q.850 code, and that therefore every response code 
> mapping should
> just be to 127 interworking.

[JRE] No, I think some have very obvious similarity of meaning, e.g., 600 to
17. However, where this is not the case, it strikes me that something has
gone wrong in the interworking process, i.e., the error would not have
arisen if not trying to interworking with a non-ISDN environment. Note that
for ISUP mapping, cause 127 has been chosen for some response codes (413,
414, 416, 420, 421, 505, 513), yet the default (31) applies to the following
from bis09 (422, 482, 487, 488, 491, 493, 501, 606) (+ any introduced in the
future). This is roughly a 50/50 split, and the rationale for choosing 31
rather than 127 is not at all clear.

> Consider your objection to the 
> SIP 408 -> ISUP
> 102 mapping: agreed that no ISUP device can alter its timers 
> in order to fix
> this error... however, the final recipient of the ISUP REL message
> containing this cause code is not the agent whose timer failed - the
> recipient can't exactly do anything itself to remedy the 
> timeout problem.
> Will the right behavior result from the receipt of the 102 
> cause code? Does
> the cause code provide the back office with a reasonable 
> depiction of why
> the error occurred (127 is very opaque)? If so, then I think we have a
> mapping. This is ultimately a philosophical difference 
> between you and I, I
> imagine.

[JRE] In fact we have re-thought the mapping for 408 - see below.

> 
> A number of the SIP response codes (including several that you mention
> below) are flagged in sipping-isup-02 with a caveat that 
> states that the
> request should be altered and retried rather than failed. 401/407 are
> perfect examples - if possible, the gateway should answer the 
> challenge
> rather than sending back a cause code 21 REL. Some of the 
> mappings (like
> 484, 415, etc) only make sense in this context. SIP first 
> tries to fix the
> protocol error itself, and only if it cannot does it send 
> back a failure
> response to the PSTN.

[JRE] I agree, and words to this effect need to be added to the QSIG mapping
draft.

> 
> It is important to remember, as you look at these mappings, that we're
> trying to characterize the behavior of a gateway. Some of the 
> mappings only
> make sense in this specific context. When an IAM arrives at a 
> gateway, it
> should send an INVITE - period. So ask yourself this - under what
> circumstances would a 405 (Method Not Allowed) return to a gateway?
> Presumably, only when a gateway sent some method other than 
> an INVITE. Why
> would it do that? Because something in the PSTN is telling it to do
> something unusual, something that in the gateway's opinion 
> requires it to
> send a method other than INVITE (like INFO, maybe, because 
> the PSTN sent a
> UUI). In light of that, I find something like '63 service/option
> unavailable' a credible mapping for 405.

[JRE]I guess this is another example of a philosophical difference. The
QSIG/ISUP network sends a SETUP/IAM to the gateway and the gateway should
send an INVITE. Any SIP entity should recognise INVITE. So something has
gone wrong in the SIP network, e.g., the gateway has issued the wrong method
or another entity has wrongly rejected it. This is an error in the SIP
network, and my preference for dealing with this is 127. There is nothing
much the calling end can do in terms of changing the contents of the
SETUP/IAM to prevent this happening.
---------------snip---------------

> > 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?
> 
> Primarily because we don't consider SIP-T networks to be 
> 'interworked'.

[JRE] Yet as I pointed out above, 127 is used in several cases. We certainly
regard the QSIG-SIP case as interworking. If ISUP-SIP is architecturally or
philosophically different, perhaps we are misguided in trying to align cause
mappings.

> Normalcy isn't well defined in Q.850, it's true.
> 
> > 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?
> 
> SIP networks, for all intents and purposes, lack the 
> distinction between a
> user and a service (in the strong sense that SS7 
> distinguished between a
> user and a switch). This causes us untold chagrin and confusion in our
> attempts to map SIP to ISUP. However, I am comfortable that 
> 401, 402, and
> 403 are reasonably 'user-level' events. I think 21 is the 
> right mapping for
> these.

[JRE] SIP does recognise user (i.e. someone or something on whose behalf the
user agent acts). By user above I meant user in a similar sense - I did not
mean the user's terminal equipment, which I agree is a philosophy more
related to ISDN than to SIP. I guess I don't feel so strongly about 403 or
402 (although 402 is "reserved for future use" in bis, so anything other
than default mapping is a little questionable). Rethinking 401, however, the
fact that the gateway is unable to authenticate itself to the UAS is an
interworking problem, and 127 might be more appropriate (see also 407
below). 

> 
> > 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"?
> 
> I am comfortable with our stated mapping here as well. 404 
> does not have any
> connotation about intermediaries being unable to route to a particular
> service provider, a concept that is a bit closer to cause 3.

[JRE] I agree cause 404 does not have any such connotation. However, the
fact that the SIP network is unable to reach the destination seems to imply
that by rerouting in the ISDN and avoiding the SIP network there may be a
better chance. However, I don't feel too strongly about this.

> 
> > 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.
> 
> I don't have a strong commitment on this one - I agree that 127 is
> reasonable, I just happen to like 63 better.

[JRE] See above.

> 
> > 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.
> 
> The question is - what Accept header field value? Why has 
> that Accept header
> been included by this gateway? That isn't internal to the SIP 
> network at
> all. Something in the PSTN has told the gateway to ask for something
> unusual.

[JRE] Again, the way I intend to view it is that the ISUP or QSIG network
has done nothing to ask for anything unusual in an Accept header, so this is
a problem in the SIP network (gateway or elsewhere).

> 
> > 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?
> 
> Again, I am comfortable that 407->21 is okay.

[JRE] Normally the gateway should repeat the attempt and authenticate itself
to the proxy. If the gateway is unable to do this, there is nothing that the
ISUP/QSIG network can do to get around the problem, i.e., it is an internal
problem of the SIP network. I am becoming more of the opinion that 127 would
be best. By similar argument, 401 should also map to 127.

> 
> > 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.
> 
> I speak to this in the notes above.
[JRE] On reconsideration, I am happy to map 504 to 102. However, it has been
pointed out to me that the semantics of 408 are very similar to the
semantics of cause 18 (no user responding), and in the reverse direction
cause 18 does indeed map to response code 408. So in
draft-elwell-sipping-qsig2sip-01 we have specified 408->18. Any comment?

> 
> > 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.
> 
> Again, what message body? Why was that message body included 
> by the gateway?
> If this were just a vanilla call, that would never happen. We want the
> status code that returns to tell the PSTN caller to do something
> differently.

JRE] The same philosophical difference.

> 
> > 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.
> 
> Temporary failure means you should retry your call later. I 
> think that is a
> reasonable mapping. Is there some difference in behavior that you are
> looking for between 127 and 41?

[JRE] I don't have such a strong feeling about this. I guess 481 should be a
temporary situation, and therefore 41 seems appropriate. On the other hand,
it is yet another case of an internal error within the SIP network, and I
believe 127 is appropriate in all these cases.

> 
> > 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.
> 
> 65 might not be a bad idea if the Warning header were 
> actually discussing
> SDP incompatibilities, agreed. It was with that sort of thing 
> in mind that
> we suggested that Warning codes might merit their own 
> mappings. I'll note
> that in the draft.

[JRE] I think 606 and 488 are exclusively concerned with SDP errors. 488
refers to 606 and 606 states "The user's agent was contacted successfully
but some aspects of the session description such as the requested media,
bandwidth, or addressing style were not acceptable." Therefore it should be
possible always to map to 65.

> 
> > 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?
> 
> Throwing 'bad gateway' is a serious, non-transient condition. 
> 38 expresses
> something a little more dire than just a temp failure. An 
> INVITE sent from a
> gateway that gets returned a 502 should be a cause for concern.

[JRE] I am not sure that 502 is non-transient - it just says that an invalid
response was received.

> 
> I'm more sympathetic to the idea that 501 and 406 should have 
> a similar
> mapping.

[JRE] Do you mean 501 and 405, since they both related to methods that can't
be handled?

_______________________________________________
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